Repository navigation
ipc4: handler: bound large config get reply size - #11327
Conversation
For a LARGE_CONFIG_GET the reply size starts as the host-controlled 20-bit data_off_size field and is only updated if the module's get_configuration() writes it back. Modules that do not (e.g. the selector, whose getter is a stub returning 0) leave it untouched, so up to ~1 MB ends up in msg_reply->tx_size. Writing that reply to the 4 KB DSP mailbox then fails in memcpy_s(). On the POSIX/fuzz platform this trips an assert inside the IPC TX work queue, whose handler re-asserts while holding a spinlock and recurses until the 2 KB thread stack overflows. The IPC fuzzer reported this as an AddressSanitizer stack-overflow. Reject reply sizes larger than MAILBOX_DSPBOX_SIZE with IPC4_INVALID_CONFIG_DATA_STRUCT in both large config get paths. Signed-off-by: Jun Lai <junlai@dolby.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
Can one of the admins verify this patch?
|
|
This PR is a fix about |
b7c08ef to
e796d85
Compare
There was a problem hiding this comment.
🟢 Approval recommended
Both guards reject oversized replies before publishing their sizes and preserve existing error handling.
No open issues 🎉
What changed in this PR
Bounds IPC4 large-configuration GET replies to prevent oversized mailbox writes and the resulting fuzz-platform crash.
Changes:
- Checks reply sizes against
MAILBOX_DSPBOX_SIZEin both GET paths. - Returns
IPC4_INVALID_CONFIG_DATA_STRUCTbefore publishing oversized replies.
| File | Description |
|---|---|
src/ipc/ipc4/handler-user.c |
Adds mailbox-size guards to both large-configuration GET paths. |
Review effort: Balanced
I'll merge whatever passes CI first as it seem we have some blockage or backlog today. |
PR 11327: test resultsRun date: 2026-10-22 15:24 UTC Tested commit: e796d8599132a4abe91899064241959217765293
|
For a LARGE_CONFIG_GET the reply size starts as the host-controlled 20-bit data_off_size field and is only updated if the module's get_configuration() writes it back. Modules that do not (e.g. the selector, whose getter is a stub returning 0) leave it untouched, so up to ~1 MB ends up in msg_reply->tx_size.
Writing that reply to the 4 KB DSP mailbox then fails in memcpy_s(). On the POSIX/fuzz platform this trips an assert inside the IPC TX work queue, whose handler re-asserts while holding a spinlock and recurses until the 2 KB thread stack overflows. The IPC fuzzer reported this as an AddressSanitizer stack-overflow.
Reject reply sizes larger than MAILBOX_DSPBOX_SIZE with IPC4_INVALID_CONFIG_DATA_STRUCT in both large config get paths.