kernel/linux.git/sound/soc/sof/ipc3-control.c, branch v7.2-rc2

ASoC: SOF: ipc3-control: Fix heap overflow in bytes_ext put/get

2026-06-09T17:41:14+00:00

The ipc_control_data buffer is allocated as kzalloc(max_size), where max_size covers the entire struct sof_ipc_ctrl_data including its flexible array payload. However, the bounds checks in bytes_ext_put and _bytes_ext_get compared user data lengths against max_size directly, ignoring that cdata->data sits at an offset of sizeof(struct sof_ipc_ctrl_data) bytes into the allocation. This allowed writing up to sizeof(struct sof_ipc_ctrl_data) bytes past the end of the heap buffer from unprivileged userspace via the ALSA TLV kcontrol interface, and similarly allowed over-reading adjacent heap data on the get path. Fix all bounds checks to subtract sizeof(*cdata) from max_size so they reflect the actual space available at the cdata->data offset. Also fix the error-path restore in bytes_ext_put which wrote to cdata->data instead of cdata, causing the same overflow. Fixes: 67ec2a091630 ("ASoC: SOF: Add bytes_ext control IPC ops for IPC3") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Liam Girdwood Reviewed-by: Bard Liao Link: https://patch.msgid.link/20260609083458.31193-7-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: ipc3-control: Fix TOCTOU in bytes_put and bytes_get

2026-06-09T17:41:13+00:00

In sof_ipc3_bytes_put(), the size used for the memcpy is derived from the old data->size already in the buffer, not the incoming new data's size field. If the new data has a different size, the copy length is wrong: it may truncate valid data or copy stale bytes. Similarly, sof_ipc3_bytes_get() checks data->size against max_size without accounting for the sizeof(struct sof_ipc_ctrl_data) offset of the flex array within the allocation. Fix bytes_put to validate and use the incoming data's sof_abi_hdr.size from ucontrol before copying. Fix bytes_get to subtract sizeof(*cdata) from the bounds check to match the actual available space. Fixes: 544ac8858f24 ("ASoC: SOF: Add bytes_get/put control IPC ops for IPC3") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Liam Girdwood Reviewed-by: Bard Liao Link: https://patch.msgid.link/20260609083458.31193-6-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: ipc3-control: Validate size in snd_sof_update_control

2026-06-09T17:41:12+00:00

In snd_sof_update_control(), firmware-provided cdata->num_elems is checked against local_cdata->data->size but never against the actual allocation size. If local_cdata->data->size was previously set to an inconsistent value, the memcpy could write past the allocated buffer. Add a bounds check to ensure num_elems fits within the available space in the ipc_control_data allocation before copying. Fixes: 10f461d79c2d ("ASoC: SOF: Add IPC3 topology control ops") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Liam Girdwood Reviewed-by: Bard Liao Link: https://patch.msgid.link/20260609083458.31193-5-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: ipc3-control: Use overflow checks in control_update size calc

2026-06-09T17:41:11+00:00

In sof_ipc3_control_update(), the expected_size calculation uses firmware-provided cdata->num_elems in arithmetic that could overflow on 32-bit platforms, wrapping to a small value. This would allow the cdata->rhdr.hdr.size comparison to pass with mismatched sizes, potentially leading to out-of-bounds access in snd_sof_update_control. Use check_mul_overflow() and check_add_overflow() to detect and reject overflowed size calculations. Fixes: 10f461d79c2d ("ASoC: SOF: Add IPC3 topology control ops") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Liam Girdwood Reviewed-by: Bard Liao Link: https://patch.msgid.link/20260609083458.31193-4-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: Intel: clarify Copyright information

2024-05-06T14:59:35+00:00

For some reason a number of files included the "All rights reserved" statement. Good old copy-paste made sure this mistake proliferated. Remove the "All rights reserved" in all Intel-copyright to align with internal guidance. Reviewed-by: Cezary Rojewski Signed-off-by: Pierre-Louis Bossart Reviewed-by: Bard Liao Reviewed-by: Péter Ujfalusi Link: https://lore.kernel.org/r/20240503140359.259762-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown

ASoC: sof: Improve sof_ipc3_bytes_ext_put function

2023-05-23T18:31:14+00:00

The function is improved in the way that if the firmware returns a validation error on the newly sent bytes, then the kernel will automatically restore to the old bytes value for a given kcontrol. This way, if the firmware rejects a data blob then the kernel will also reject it, instead of saving it for the next suspend/resume cycle. The old behaviour is that the kernel would save it anyway and on next firmware boot it would apply the previously-rejected configuration, leading to errors during playback. Additionally, the function also saves previously validated configurations, so that if the firmware does end up rejecting a new bytes value the kernel can send an old, previously-valid configuration. Reviewed-by: Daniel Baluta Reviewed-by: Péter Ujfalusi Signed-off-by: Paul Olaru Signed-off-by: Daniel Baluta Link: https://lore.kernel.org/r/20230503081049.73847-2-daniel.baluta@oss.nxp.com Signed-off-by: Mark Brown

ASoC: SOF: ipc3-control: Merge functions to handle bytes_ext get variants

2023-03-13T14:06:49+00:00

The code for bytes_ext_get and bytes_ext_volatile_get is identical with the only difference is that in case of volatile_get we refresh the data from the DSP before returning it to user space. Convert the callbacks to a simple wrapper for the same function. Signed-off-by: Peter Ujfalusi Reviewed-by: Pierre-Louis Bossart Reviewed-by: Ranjani Sridharan Link: https://lore.kernel.org/r/20230313110344.16644-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: ipc3-control: Rename snd_sof_refresh_control()

2023-03-13T14:06:48+00:00

Rename the snd_sof_refresh_control() to sof_ipc3_refresh_control() to follow the function naming convention for IPC specific code. Signed-off-by: Peter Ujfalusi Reviewed-by: Pierre-Louis Bossart Reviewed-by: Ranjani Sridharan Link: https://lore.kernel.org/r/20230313110344.16644-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: Protect swidget->use_count with mutex for kcontrol access race

2023-01-27T12:14:12+00:00

The use_count of the swidget is protect by ALSA core PCM locking with the exception when an associated kcontrol is changed. It has been observed that a rightly timed kcontrol access during stream stop can result of an attempt to send a control update to a widget which has been freed up between the check of the use_count and the message sending. We need to protect the entire sof_widget_setup() and sof_widget_free() execution to make it safe to rely on the use_count. Move the code under an _unlocked() function and use a mutex to protect the execution of the functions for concurrency. On the control path we need to use the lock only for the kcontrol access, the widget_kcontrol_setup() op is called with the lock already held. Reported-by: Guennadi Liakhovetski Signed-off-by: Peter Ujfalusi Reviewed-by: Pierre-Louis Bossart Reviewed-by: Ranjani Sridharan Link: https://lore.kernel.org/r/20230127120031.10709-18-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: ipc3: Remove the ipc3-ops.h header file

2022-05-04T14:31:18+00:00

Only the main IPC ops struct should be visible outside of IPC3 code to make sure that the code is correctly abstracted. Instead of keeping the ipc3-ops.h with only the high level ops struct declaration, put the ipc3_ops to sof-priv.h and move all other ops struct declaration into ipc3-priv.h New IPC implementation should follow this route: the main IPC ops should be declared in sof-priv.h and no other IPC version related header be used for generic code. Signed-off-by: Peter Ujfalusi Reviewed-by: Pierre-Louis Bossart Reviewed-by: Ranjani Sridharan Reviewed-by: Bard Liao Link: https://lore.kernel.org/r/20220504102831.10071-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown