ipc4: handler: reject get_large_config vendor payload larger than hostbox

[tmleman]

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.

[Copilot]

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_SIZE upper-bound check for data_off_size in ipc4_get_large_config_module_instance() when handling VENDOR_CONFIG_PARAM.
• Return IPC4_INVALID_CONFIG_DATA_STRUCT and log an error before any cache invalidation or hostbox parsing occurs.