ipc4: handler: reject get_large_config vendor payload larger than hostbox#10851
Open
tmleman wants to merge 1 commit into
Open
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
This PR hardens the IPC4 “get large config” vendor-param path by rejecting host-provided data_off_size values that exceed the physical hostbox size, preventing cache maintenance over-range and out-of-bounds hostbox reads.
Changes:
- Add a
MAILBOX_HOSTBOX_SIZEupper-bound check fordata_off_sizeinipc4_get_large_config_module_instance()when handlingVENDOR_CONFIG_PARAM. - Return
IPC4_INVALID_CONFIG_DATA_STRUCTand log an error before any cache invalidation or hostbox parsing occurs.
serhiy-katsyuba-intel
approved these changes
Jun 8, 2026
…tbox
ipc4_get_large_config_module_instance() reads config.extension.r.data_off_size
straight from the host message and, for the VENDOR_CONFIG_PARAM case, uses it
without an upper bound:
* dcache_invalidate_region() is asked to invalidate that many bytes starting
at MAILBOX_HOSTBOX_BASE, and
* ipc4_get_vendor_config_module_instance() computes
tl_count = data_off_size / sizeof(struct sof_tl) and walks that many TL
records straight out of the hostbox.
data_off_size is a 20-bit field, so it can claim up to ~1 MB while the hostbox
is only MAILBOX_HOSTBOX_SIZE (SOF_IPC_MSG_MAX_SIZE) bytes. The symmetric set
path already rejects this in ipc4_set_vendor_config_module_instance()
("data_off_size ... > MAILBOX_HOSTBOX_SIZE"), the get path was missing the
same guard, leaving a cache-maintenance over-range on real hardware and an
out-of-bounds hostbox read for any vendor param that returns success with a
zero-length value (which keeps produced_data from advancing the DSPBOX cap
that otherwise terminates the loop early).
Found by audit while reviewing the IPC4 hostbox readers surfaced by the fuzz
harness, not by a live crash: on native_sim CONFIG_CACHE is unset so the
invalidate is a no-op, and the common TL walk is bounded in practice by the
DSPBOX size check. Convert the missing bound into a hard rejection before the
region is touched, mirroring the set path.
Signed-off-by: Tomasz Leman <tomasz.m.leman@intel.com>
lgirdwood
reviewed
Jun 8, 2026
| /* data_off_size is a 20-bit host-controlled field, so it can | ||
| * claim far more than the hostbox can physically hold. | ||
| */ | ||
| if (data_offset > MAILBOX_HOSTBOX_SIZE) { |
Member
There was a problem hiding this comment.
Do we need to include the container size or current offset in the calculation ? e.g. if object size + data_offset > MAILBOX_SIZE ?
Collaborator
There was a problem hiding this comment.
I think data is set to start of the mailbox, so this would be correct.
kv2019i
approved these changes
Jun 8, 2026
| /* data_off_size is a 20-bit host-controlled field, so it can | ||
| * claim far more than the hostbox can physically hold. | ||
| */ | ||
| if (data_offset > MAILBOX_HOSTBOX_SIZE) { |
Collaborator
There was a problem hiding this comment.
I think data is set to start of the mailbox, so this would be correct.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
ipc4_get_large_config_module_instance() reads config.extension.r.data_off_size straight from the host message and, for the VENDOR_CONFIG_PARAM case, uses it without an upper bound:
data_off_size is a 20-bit field, so it can claim up to ~1 MB while the hostbox is only MAILBOX_HOSTBOX_SIZE (SOF_IPC_MSG_MAX_SIZE) bytes. The symmetric set path already rejects this in ipc4_set_vendor_config_module_instance() ("data_off_size ... > MAILBOX_HOSTBOX_SIZE"), the get path was missing the same guard, leaving a cache-maintenance over-range on real hardware and an out-of-bounds hostbox read for any vendor param that returns success with a zero-length value (which keeps produced_data from advancing the DSPBOX cap that otherwise terminates the loop early).
Found by audit while reviewing the IPC4 hostbox readers surfaced by the fuzz harness, not by a live crash: on native_sim CONFIG_CACHE is unset so the invalidate is a no-op, and the common TL walk is bounded in practice by the DSPBOX size check. Convert the missing bound into a hard rejection before the region is touched, mirroring the set path.