ipc4: handler: bound get_large_config reply size to the reply buffer

[lgirdwood]

What this fixes

The simple-IPC-fuzz_sh job has been failing intermittently on unrelated PRs
(#11193, #11208, #11214, #11227 among them). The CI log only ever shows this:

==6279==ERROR: AddressSanitizer: stack-overflow on address 0xddedfffc (T8)
    #3 vfprintf
    #5 nsi_vprint_trace  zephyr/scripts/native_simulator/native/src/nsi_trace.c:94
    #6 posix_print_trace zephyr/boards/native/native_sim/posix_arch_if.c:61
Thread T8 created by T3 here:
    #7 k_work_queue_start zephyr/kernel/work.c:875
    #8 ipc_init           sof/src/ipc/ipc-common.c:799

That report is a red herring. The real failure is a Zephyr assert; the
assert -> k_panic -> z_spin_lock_valid assert loop that follows it is what
eventually exhausts the 8MB pthread stack native_sim gives the ipc_send_wq
thread. The actual assert text goes to stdout, which fuzz.sh closes via
-close_fd_mask=1 whenever -jobs > 1, so only the secondary ASan report on
stderr reaches the log.

Replaying the crash artifact locally shows the real failure immediately:

ASSERTION FAIL [!dsp_write_err] @ sof/src/include/sof/lib/mailbox.h:52

#1 mailbox_dspbox_write (offset=0, bytes=918016) sof/src/include/sof/lib/mailbox.h:52
#2 ipc_platform_send_msg (msg=0x7504c0 <msg_reply>) sof/src/platform/posix/ipc.c:435
#3 ipc_send_queued_msg ()                          sof/src/ipc/ipc-common.c:218
#4 ipc_work_handler (work=...)                     sof/src/ipc/ipc-common.c:386

A reply claiming ~900KB of payload for a 4KB mailbox.

Root cause

ipc4_get_large_config_module_instance() seeds data_offset from
config->extension.r.data_off_size — a 20-bit host-controlled field — and
passes it to drv->ops.get_large_config() as an in/out parameter. A module
whose .get_configuration produces no data returns success without writing
*data_offset_size, so the host-supplied value survives unchanged and is
published as msg_reply->tx_size. The payload itself lives in
ipc->comp_data, which is only SOF_IPC_MSG_MAX_SIZE bytes.

template_get_config() is the stub the fuzzer happened to find — it is
explicitly documented as "Not used in IPC4 systems" and just returns 0 — but
any IPC3-oriented .get_configuration behaves the same way.

Only the VENDOR_CONFIG_PARAM branch bounds data_off_size today (added in
d94306c), and it does so for the inbound hostbox read, not for the reply.

With asserts compiled out this is not merely cosmetic: memcpy_s() rejects
the copy but its return value is discarded, dcache_writeback_region() is
still asked to write back the out-of-range length, and the caller goes on to
send a reply header advertising a size that was never copied.

The change

Bound the reply size against the space actually left in the reply buffer
before it is published, and fail the command with
IPC4_INVALID_CONFIG_DATA_LEN otherwise. The bound is computed from data
rather than from SOF_IPC_MSG_MAX_SIZE directly because the non-vendor branch
advances data by sizeof(reply) under CONFIG_LIBRARY.

The same fix is applied to ipc4_process_large_config_get(), the
CONFIG_SOF_USERSPACE_LL variant, which has the identical flaw (and also
lacks the vendor-path hostbox bound its sibling has — not addressed here).

Verification

Built for native_sim/native/64 and replayed the crash artifacts from two
independent failing CI runs:

artifact	before	after
crash-cd99ca2d... (PR #11193, job simple-IPC-fuzz_sh (4))	ASSERTION FAIL [!dsp_write_err], rc=1	rc=0
crash-15eb8d66... (PR #11208, job simple-IPC-fuzz_sh (4))	ASSERTION FAIL [!dsp_write_err], rc=1	rc=0

Two independently-found inputs hitting the identical assert is what makes me
fairly confident this is the single root cause behind the recent intermittent
failures, rather than one of several.

Under gdb the new branch is confirmed to be the one taken:
data_offset = 918016, data_max = 4096, ret = 121
(IPC4_INVALID_CONFIG_DATA_LEN).

Also:

• 420s x 8-job fuzz run over a ~10k-input corpus: no new crash artifacts.
• intel_adsp/ace30/ptl cross-build clean.
• checkpatch clean at SOF's 100-column limit.

Left alone deliberately

Two things make any fuzz assert much harder to diagnose than it should be.
Both look worth separate patches, and I would rather not fold them into a
fix:

1. The assert recursion. ipc_send_queued_msg() holds ipc->lock when
   the assert fires, and the fatal path then trips z_spin_lock_valid()
   repeatedly, so any fuzz assert degenerates into an 8MB stack overflow
   instead of stopping at the assert.
2. -close_fd_mask=1. With -jobs > 1 this discards the one line that
   identifies the bug.

Marked draft pending CI.

🤖 Generated with Claude Code

[tmleman]

@lgirdwood is this the PR you mentioned in #11237 (comment)?

These changes address a different issue, I also came across it in my nightly fuzzer runs. The fix is good. I would probably just remove the comments. They seem unnecessary.

[Copilot]

🟢 Approval recommended

The bounds checks correctly account for payload offsets and cover both affected reply paths.

0 open findings

What changed in this PR

Bounds IPC4 large-config reply sizes to prevent oversized mailbox writes from host-controlled values.

Changes:

• Validates reply payload size against remaining IPC buffer capacity.
• Applies validation to kernel and userspace LL paths.

File	Description
src/​ipc/​ipc4/​handler-user.c	Rejects oversized large-config replies with IPC4_INVALID_CONFIG_DATA_LEN.

🧠 Review effort: Balanced

---

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

[lgirdwood]

@lgirdwood is this the PR you mentioned in #11237 (comment)?

These changes address a different issue, I also came across it in my nightly fuzzer runs. The fix is good. I would probably just remove the comments. They seem unnecessary.

Thanks @tmleman - I'd forgotten about this as last two weeks have been very busy, and thanks for confirming its not the same fix as your PR. Now made non draft.

Comments good for me as descriptive, yes Claude is very verbose on the commit message, but I've found deep diving the fuzzer integration time consuming so any context is helpful.

[lgirdwood]

SOFCI TEST

[intel-sofci]

PR 11239: test results

Run date: 2026-10-10 10:54 UTC

Tested commit: 46016cb03e290bf1f482179f53de04fa9acf3cd1