audio: selector: check source and sink buffers before prepare

[tmleman]

The IPC4 fuzzer hit a NULL pointer dereference in selector_prepare(). ASan reports a READ SEGV at address 0x10 in
audio_buffer_hw_params_configured() reached from set_selector_params(), UBSan reports "member access within null pointer of type 'struct comp_buffer'" at selector.c set_selector_params().

The host can instantiate a selector (MICSEL) in a pipeline and send SET_PIPELINE_STATE before binding any buffers to it. Prepare then runs with empty source and sink lists, and set_selector_params() takes comp_dev_get_first_data_producer() == NULL and dereferences src_buf->audio_buffer.audio_stream_params (offset 0x10). The rest of selector_verify_params() and selector_prepare() also use the first producer/consumer without checking them.

Look the buffers up at the start of selector_prepare() and fail with -ENOTCONN if either is missing, as eq_iir does. Valid topologies always bind the selector before prepare, so this does not reject legitimate configurations.

[Copilot]

🟡 Changes recommended

The validation occurs after selector_params() already dereferences the missing buffers.

1 open finding

• Validate selector buffers before selector_params() to prevent crash · New

What changed in this PR

Adds buffer validation intended to prevent NULL dereferences when preparing an unbound IPC4 selector.

Changes:

• Returns -ENOTCONN when source or sink buffers are absent.

File	Description
src/​audio/​selector/​selector.c	Adds IPC4 selector buffer validation.

🧠 Review effort: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[intel-sofci]

PR 11305: test results

Run date: 2026-10-15 07:52 UTC

Tested commit: 1ca5b7704ffff081288d18cc8c2e6eb8b705e4ee

[softwarecki]

Please check num_of_sources and num_of_sinks instead. No new use od struct comp_buffer. It will be removed soon.

[lgirdwood]

Please check num_of_sources and num_of_sinks instead. No new use od struct comp_buffer. It will be removed soon.

@softwarecki do you have an ETA for this ? I guess we need all P20 PRs to land first, I think some still needing copilot reviews resolved but otherwise they are good.

[softwarecki]

@lgirdwood: When I wrote "soon", I was thinking more about the final stage of the transition to pipeline 2.0 rather than the next few weeks.

The current plan is to finish the remaining module conversions (only tdfb and cadence are left) and then clean up module_adapter by removing deprecated processing functions. Before comp_buffer can be removed, we will also need to rework the module binding mechanism, which is another larger planned task.

For that reason, I would prefer to avoid introducing new uses of comp_buffer. Any new usage would have to be reworked later anyway when we complete the migration and remove it entirely.