Skip to content

audio: tdfb: Improve robustness for invalid configuration#10877

Merged
lgirdwood merged 1 commit into
thesofproject:mainfrom
singalsu:tdfb_updates
Jun 12, 2026
Merged

audio: tdfb: Improve robustness for invalid configuration#10877
lgirdwood merged 1 commit into
thesofproject:mainfrom
singalsu:tdfb_updates

Conversation

@singalsu

@singalsu singalsu commented Jun 11, 2026

Copy link
Copy Markdown
Collaborator

Add several validity checks against malformed configuration blobs and malformed IPC control payloads.

@singalsu singalsu marked this pull request as ready for review June 11, 2026 14:19
Copilot AI review requested due to automatic review settings June 11, 2026 14:19

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Pull request overview

This PR hardens the TDFB (time-domain fixed beamformer) module against malformed configuration blobs and malformed IPC3 control payloads, aiming to prevent invalid offset arithmetic and out-of-bounds accesses when parsing untrusted inputs.

Changes:

  • Track and validate configuration blob size end-to-end (cd->config_size) and add multiple config field validity checks (e.g., angle_enum_mult, filter_index, negative channel selects).
  • Add IPC3 GET handler validation for cdata->num_elems to avoid overrunning the control payload.
  • Increase the stack array used in theoretical time-difference calculation to support up to SOF_TDFB_MAX_MICROPHONES.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

File Description
src/audio/tdfb/tdfb.c Adds blob-size tracking and additional config sanity checks during coefficient init and runtime blob updates.
src/audio/tdfb/tdfb_ipc3.c Rejects invalid num_elems values in IPC3 GET handling to prevent payload overruns.
src/audio/tdfb/tdfb_direction.c Enlarges a local array to support up to 16 microphone locations.
src/audio/tdfb/tdfb_comp.h Adds config_size field to persist blob size for validation.

Comment thread src/audio/tdfb/tdfb.c
Comment thread src/audio/tdfb/tdfb.c
Comment thread src/audio/tdfb/tdfb_direction.c
Add validity checks against malformed configuration blobs and IPC
control payloads:

- Bound the blob length reported by comp_get_data_blob() to
  [sizeof(*cd->config), SOF_TDFB_MAX_SIZE] in both tdfb_prepare and the
  runtime new-blob path; store it in cd->config_size and require
  config->size to match in tdfb_init_coef.
- Bump SOF_TDFB_MAX_SIZE 4096 -> 16384 to match the topology budget.
- Tie SOF_TDFB_MAX_MICROPHONES to PLATFORM_MAX_CHANNELS so num_mic_locations
  cannot exceed the per-channel direction state arrays in tdfb_comp.h.
- Reject num_angles == 0, angle_enum_mult == 0, negative or out-of-range
  filter_index, and negative input_channel_select[].
- Check cdata->num_elems vs. SOF_IPC_MAX_CHANNELS in the IPC3 GET handler.

Signed-off-by: Seppo Ingalsuo <seppo.ingalsuo@linux.intel.com>

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.

Comments suppressed due to low confidence (1)

src/audio/tdfb/tdfb.c:380

  • tdfb_filter_seek() walks num_filters coefficient blocks by reading each sof_fir_coef_data->length from the blob, but it has no bounds checking against config->size/cd->config_size. With a malformed blob (e.g., a large length), this can advance coefp past the end of the allocation and then dereference out-of-bounds in the next iteration, before the later end-of-blob size check runs.
	/* Skip filter coefficients */
	num_filters = config->num_filters * (config->num_angles + config->beam_off_defined);
	coefp = tdfb_filter_seek(config, num_filters);

Comment thread src/audio/tdfb/tdfb.c
Comment on lines +360 to +363
if (!config->angle_enum_mult) {
comp_err(dev, "invalid angle_enum_mult");
return -EINVAL;
}

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

With negative multiplier it's possible to generate a descending angle scale. It could be useful, no need to limit the usage. The angles are negative and positive any way via the angle offset parameter.

Comment thread src/audio/tdfb/tdfb.c
Comment on lines +326 to +329
if (config->size != cd->config_size) {
comp_err(dev, "Incorrect configuration blob size");
return -EINVAL;
}

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

Since the blobs are created with a tool (not manually) the size mismatch is very unlikely. No need for more details.

Comment thread src/audio/tdfb/tdfb.c
Comment on lines 659 to +665
if (comp_is_new_data_blob_available(cd->model_handler)) {
cd->config = comp_get_data_blob(cd->model_handler, NULL, NULL);
cd->config = comp_get_data_blob(cd->model_handler, &cd->config_size, NULL);
if (!cd->config || cd->config_size < sizeof(*cd->config) ||
cd->config_size > SOF_TDFB_MAX_SIZE) {
comp_err(dev, "invalid configuration blob, size %zu", cd->config_size);
return -EINVAL;
}

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

I propose to add the blob validator later. I have started the work but it won't be ready before summer vacations that this PR targets for.

struct tdfb_comp_data *cd = module_get_private_data(mod);

if (cdata->num_elems == 0 || cdata->num_elems > SOF_IPC_MAX_CHANNELS)
return -EINVAL;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

only bytes controls will have num_elems as 0 as the hos does not know the size, for any other controls the host sets num_elems: data->num_elems = scontrol->num_channels;, the num_channels comes from topology and only checked against SND_SOC_TPLG_MAX_CHAN, no check for 0 anywhere, not even in core, a control is allowed to have 0 channels?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

I'm not even sure the num_elems strictly means number of stream channels. It might be e.g. graphical EQ bands number that could be larger than max. channels count, e.g. 10 vs. 8. Can the cdata buffer allocation be too small for the num_elems ever?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

With current implementation of the control the components generally can decide the usage, the control can be per channel, or as "mono" a control for all channels, or with non-associated to channels something else like the graphical EQ bands controls. In this case with the current IIR implementation, the SOF_IPC_MAX_CHANNELS check isn't limiting any functionality so it can be kept.

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.

atm, lets keep the validation in the module for valid channel count in kcontrols as they will be different.

@lgirdwood lgirdwood merged commit 569e54f into thesofproject:main Jun 12, 2026
45 checks passed
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.

5 participants