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

ASoC: SOF: ipc4-control: Validate notification payload size

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

Validate MODULE_NOTIFICATION payload length before reading bytes/channel data in control update handling. Fixes: 2a28b5240f2b ("ASoC: SOF: ipc4-control: Add support for generic bytes control") 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-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: ipc4-control: Fix TOCTOU in sof_ipc4_bytes_put

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

In sof_ipc4_bytes_put(), the copy size is derived from the old data->size in the buffer rather than the incoming new data's size field from ucontrol. If the new data has a different size, the copy uses the wrong length: it may truncate valid data or copy stale bytes. Fix by validating and using the incoming data's sof_abi_hdr.size from ucontrol before copying. Fixes: a062c8899fed ("ASoC: SOF: ipc4-control: Add support for bytes control get and put") 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-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: ipc4-control: Use local copy of IPC message for sending

2026-05-21T11:07:52+00:00

If a kcontrol update comes to a control right at the same time when the PCM containing the control is started up then there is a small window when a race can happen: while the widget is set up the swidget->setup_mutex is taken in topology level and if the control update comes at this point, it will be stopped within sof_ipc4_set_get_kcontrol_data() with the mutex and it will be blocked until the swidget setup is done, which will clear the control's IPC message payload. To avoid such race, use local copy of the template IPC message instead of the template directly. This will ensure data integrity in case of concurrent updates during initialization. Link: https://github.com/thesofproject/linux/issues/5734 Signed-off-by: Peter Ujfalusi Reviewed-by: Kai Vehmanen Reviewed-by: Bard Liao Link: https://patch.msgid.link/20260520141349.9625-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: ipc4-control: Set correct error code in refresh_bytes_control

2026-02-09T12:27:28+00:00

Return -EINVAL in case the scontrol contains more data than the amount of space available for it to store in sof_ipc4_refresh_bytes_control(). Reported-by: Dan Carpenter Closes: https://lore.kernel.org/linux-sound/aYXvFr-LVHVJSvS7@stanley.mountain/ Fixes: 2a28b5240f2b ("ASoC: SOF: ipc4-control: Add support for generic bytes control") Signed-off-by: Peter Ujfalusi Link: https://patch.msgid.link/20260209120239.6066-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: ipc4-control: Add support for generic bytes control

2025-12-17T16:35:51+00:00

The generic byte control can be used in cases when the bytes data can be changed by the firmware and it sends a notification about the change, similarly to the enum and switch controls. The generic control support is needed as from the param_id itself it is not possible to know which control has changed. The needed information is only available via generic control change notification. Generic bytes controls use param_id 202 and their change notification can contain payload with the change embedded or just the header message as notification. Signed-off-by: Peter Ujfalusi Reviewed-by: Seppo Ingalsuo Reviewed-by: Ranjani Sridharan Reviewed-by: Bard Liao Reviewed-by: Kai Vehmanen Link: https://patch.msgid.link/20251217143945.2667-9-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: ipc4-control: Keep the payload size up to date

2025-12-17T16:35:47+00:00

When the bytes data is read from the firmware, the size of the payload can be different than what it was previously. For example when the topology did not contained payload data at all for the control, the data size was 0. For get operation allow maximum size of payload to be read and then update the sizes according to the completed message. Similarly, keep the size in sync when updating the data in firmware. With the change we will be able to read data from firmware for bytes controls which did not had initial payload defined in topology. Fixes: a062c8899fed ("ASoC: SOF: ipc4-control: Add support for bytes control get and put") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Seppo Ingalsuo Reviewed-by: Ranjani Sridharan Reviewed-by: Bard Liao Reviewed-by: Kai Vehmanen Link: https://patch.msgid.link/20251217143945.2667-5-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: ipc4-control: Use the correct size for scontrol->ipc_control_data

2025-12-17T16:35:46+00:00

The size of the data behind scontrol->ipc_control_data is stored in scontrol->size, use this when copying data for backup/restore. Fixes: db38d86d0c54 ("ASoC: sof: Improve sof_ipc4_bytes_ext_put function") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Seppo Ingalsuo Reviewed-by: Ranjani Sridharan Reviewed-by: Bard Liao Reviewed-by: Kai Vehmanen Link: https://patch.msgid.link/20251217143945.2667-4-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: ipc4-control: If there is no data do not send bytes update

2025-12-17T16:35:44+00:00

When the bytes control have no data (payload) then there is no need to send an IPC message as there is nothing to send. Fixes: a062c8899fed ("ASoC: SOF: ipc4-control: Add support for bytes control get and put") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Seppo Ingalsuo Reviewed-by: Ranjani Sridharan Reviewed-by: Bard Liao Reviewed-by: Kai Vehmanen Link: https://patch.msgid.link/20251217143945.2667-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: ipc4-control: Use SOF_CTRL_CMD_BINARY as numid for bytes_ext

2025-05-09T09:20:13+00:00

The header.numid is set to scontrol->comp_id in bytes_ext_get and it is ignored during bytes_ext_put. The use of comp_id is not quite great as it is kernel internal identification number. Set the header.numid to SOF_CTRL_CMD_BINARY during get and validate the numid during put to provide consistent and compatible identification number as IPC3. For IPC4 existing tooling also ignored the numid but with the use of SOF_CTRL_CMD_BINARY the different handling of the blobs can be dropped, providing better user experience. Reported-by: Seppo Ingalsuo Closes: https://github.com/thesofproject/linux/issues/5282 Fixes: a062c8899fed ("ASoC: SOF: ipc4-control: Add support for bytes control get and put") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi Reviewed-by: Seppo Ingalsuo Reviewed-by: Ranjani Sridharan Reviewed-by: Liam Girdwood Link: https://patch.msgid.link/20250509085633.14930-1-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