Skip to content

audio: multiband_drc: bound num_elems in IPC3 switch getter - #11278

Open
Shrusti-pk wants to merge 1 commit into
thesofproject:mainfrom
Shrusti-pk:mbdrc-num-elems-bound
Open

Shrusti-pk wants to merge 1 commit into
thesofproject:mainfrom
Shrusti-pk:mbdrc-num-elems-bound

Conversation

@Shrusti-pk

Copy link
Copy Markdown

multiband_drc_cmd_get_value fills the reply array before it validates how many elements were asked for:

  • num_elems comes straight off the host SOF_IPC_COMP_GET_VALUE message; ipc_comp_value does not check it and the IPC3 GET_VALUE path in module_adapter_cmd passes 0 as fragment_size, so nothing bounds the loop
  • the reply buffer is ipc->comp_data, one SOF_IPC_MSG_MAX_SIZE heap block (384 bytes for IPC3), and chanv starts 92 bytes into it, so only 36 elements fit; num_elems 37 writes four bytes past the allocation and a large count walks well beyond it
  • the "num_elems should be 1" warning runs after the loop, so it never prevents anything
  • tdfb_cmd_get_value, igo_nr_get_config, rtnr_get_config and volume_get_config all reject num_elems above SOF_IPC_MAX_CHANNELS first; this is the only IPC3 switch getter left without that bound

Verified under ASan with the getter built against the real ipc/control.h: num_elems 37 is a four byte heap-buffer-overflow write zero bytes past the 384 byte comp_data block, and with the bound in place num_elems of 1 and 8 behave exactly as before.

multiband_drc_cmd_get_value() fills cdata->chanv[j].value for j in
[0, cdata->num_elems) and only afterwards looks at num_elems: the
"num_elems should be 1" warning is emitted once the loop has already
run, so it never prevents anything.

num_elems is taken verbatim from the host SOF_IPC_COMP_GET_VALUE
message. ipc_comp_value() does not validate it, and the IPC3 GET_VALUE
path in module_adapter_cmd() passes 0 as fragment_size, so nothing
bounds the loop. The reply buffer is ipc->comp_data, a single
SOF_IPC_MSG_MAX_SIZE heap block (384 bytes for IPC3), and chanv starts
92 bytes into it, so only 36 elements fit. num_elems = 37 writes four
bytes past the allocation and a large count walks well beyond it.

Reject num_elems above SOF_IPC_MAX_CHANNELS before the loop, the same
bound tdfb_cmd_get_value(), igo_nr_get_config(), rtnr_get_config() and
volume_get_config() already apply. Requests of up to one element per
channel behave as before.

Signed-off-by: Shrushti P K <shrusthi@labs.digiscrypt.com>
@Shrusti-pk
Shrusti-pk requested a review from a team as a code owner October 7, 2026 05:55
@sofci

sofci commented Oct 7, 2026

Copy link
Copy Markdown
Collaborator

Can one of the admins verify this patch?

reply test this please to run this test once

@abonislawski abonislawski left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CI triggered

@intel-sofci

Copy link
Copy Markdown

PR 11278: test results

Run date: 2026-10-08 15:24 UTC

Tested commit: e23f138088d8e6168216e491f908f7374f069374

mtl pass rate lnl pass rate ptl pass rate wcl pass rate nvl pass rate

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants