CVE-2026-72301

This CVE targets two bugs in the SOF (Sound Open Firmware) IPC3 control path that share a common root cause: desynchronized size metadata at different struct levels. Understanding both is essential for proper remediation. In `sof_ipc3_bytes_put()`, the code uses `data->size` (the buffer's existing size field) to bound a memcpy sourced from `ucontrol` data that carries its own `sof_abi_hdr.size`. These two fields diverge whenever the incoming payload differs from what was previously written. The copy length is therefore wrong whenever they don't match — this is not a missing bounds check, it's consulting the wrong size field entirely. The companion bug in `sof_ipc3_bytes_get()` compounds the pattern. The bounds check compares `data->size` directly against `max_size`, but `max_size` describes the entire allocation including the `struct sof_ipc_ctrl_data` header. The actual usable payload begins after that header. The check should subtract `sizeof(*cdata)` to yield the true available space. The struct members exist in plain sight, but the failure to account for their layout when validating reads is precisely the kind of offset error that passes normal review. Both bugs reflect a systemic condition: as ASoC IPC structures evolved, size and bounds information was added or repositioned at multiple levels (flex array header vs. container struct) without updating all usage sites. The code looks reasonable — check size, copy data — but it's using the wrong size from the wrong structural level. This creates a deceptive environment where code appears correct but is fundamentally misaligned with the allocation hierarchy. The blast radius matters here. These functions sit at the chokepoint of all SOF audio configuration flows, including firmware loading paths that can reach privilege boundaries. The chokepoint topology combined with struct desynchronization means wrong copy lengths can corrupt adjacent kernel heap structures. Remediation requires two things: first, patching both call sites with the correct size fields and offset arithmetic; second, auditing other ASoC IPC paths for identical struct layering patterns where the same desynchronization can occur. The IPC3 subsystem carries structural debt from the IPC3/IPC4 split — code that was ported but whose struct semantics didn't travel with it. Consider this CVE evidence that the entire IPC3 control path needs semantic review, not just these two functions.

Reviewed through automated stages and approved by a human before publication.