CVE-2026-72304 in the SOF driver (sof_ipc4_bytes_put) is a TOCTOU flaw where the function receives two size values — an existing buffer's metadata and an incoming parameter — and incorrectly uses the buffer's size rather than the incoming parameter's size when performing the copy. This is an API design failure, not merely an implementation oversight. The abstraction forces developers to override their intuition about state ownership, creating a latent assumption that passes review until it doesn't. The fix is trivial: validate and use the incoming parameter size. But this triviality is cold comfort — the function has sat in plain sight since 2022.
The blast radius matters more than the EPSS score (0.00163) suggests. This code path marshals userspace data into kernel buffers that interface with DMA-capable audio hardware. That's not just memory corruption — that's a potential info-leak channel to hardware, and potentially a primitive for reaching other subsystems. The audio subsystem's direct exposure via ALSA means every userspace audio client is a potential trigger vector. The EPSS captures exploitation complexity, not blast geometry.
Audit the broader IPC4 control path. Other functions in this call chain likely carry similar dual-size parameter patterns with implicit state precedence assumptions. The genotype here — size confusion in kernel audio paths with userspace exposure — has appeared before in different codec drivers, was patched individually, and the lesson was never structurally absorbed. The structural fix would be eliminating the dual-size parameter entirely from the API contract, but that breaking change won't happen, which means you're hunting the same pattern across adjacent call sites.
Prioritize patching. The firmware interaction angle is under-examined: DMA-capable audio paths involve DSP firmware that likely has weaker validation of the same size fields. The kernel-side fix closes one vector, but the firmware-side assumptions about size precedence may remain exploitable.