Fix a potential integer overflow vulnerability in trace_filter_parse()
where the allocation size calculation could overflow.
The issue occurs when:
1. capacity is calculated by adding TRACE_FILTER_ELEMENTS_PER_ENTRY in a
loop for each entry found in the input string.
2. capacity * sizeof(**out) multiplication could overflow if many
entries are present in the input.
3. This results in a smaller allocation than expected, leading to
potential buffer overflow.
Replace kmalloc() with kmalloc_array() which provides built-in overflow
checking and will safely fail the allocation if overflow would occur,
preventing memory corruption.
Signed-off-by: Samasth Norway Ananda <samasth.norway.ananda@oracle.com>
Link: https://patch.msgid.link/20250909225111.3740029-1-samasth.norway.ananda@oracle.com
Signed-off-by: Mark Brown <broonie@kernel.org>
trace_filter_parse() allocs memory for *out and when
-ENOMEM is returned, caller function, dfsentry_trace_filter_write()
trying to freed this memory.
After this patch, the memory is freed in trace_filter_parse()
before -EINVAL returned. In caller function removed kfree(elms)
from error label
Signed-off-by: Kamil Duljas <kamil.duljas@gmail.com>
Link: https://lore.kernel.org/r/20231116220102.2097-2-kamil.duljas@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This doesn't check how many bytes the simple_write_to_buffer() writes to
the buffer. The only thing that we know is that the first byte is
initialized and the last byte of the buffer is set to NUL. However
the middle bytes could be uninitialized.
There is no need to use simple_write_to_buffer(). This code does not
support partial writes but instead passes "pos = 0" as the starting
offset regardless of what the user passed as "*ppos". Just use the
copy_from_user() function and initialize the whole buffer.
Fixes: 671e0b9005 ("ASoC: SOF: Clone the trace code to ipc3-dtrace as fw_tracing implementation")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://lore.kernel.org/r/74148292-ce4d-4e01-a1a7-921e6767da14@moroto.mountain
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>:
This series handles the race which can result missing the first position update
after the trace is enabled.
In short: the firmware might send the position update (if we have enough
trace data generated) after the dma-trace is enabled by the TRACE_DMA_PARAMS_EXT
message. Depending on scheduling, load, preemption on Linux side we have seen
that occasionally this first position update got missed and we missed reading it
out.
A new state and more strict handling of host_offset can overcome this issue,
making the dtrace more reliable.
With the new state we can make sure we are not missing the first
host_offset update.
In case the dtrace is small, the DMA copy will be fast and depending on
the moonphase it might be done before we set the sdev->dtrace_state to
SOF_DTRACE_ENABLED.
The DMA will start the copy as soon as the host starts the DMA. Set the
dtrace to enabled before we let the DMA to run in order to avoid missing
the position update.
The new state is needed to cover architectures where the host side
snd_sof_dma_trace_trigger() is a NOP and the dtrace in the firmware is
ready as soon as the IPC message has been processed.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20220610080119.30880-2-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Samasth Norway Ananda