CVE-2026-72302

CVE-2026-72302 is being characterized as an integer overflow in SOF IPC3 control handling, but the real security boundary it exposes isn't between kernel and userspace — it's between firmware and the kernel. The vulnerability occurs when `num_elems`, a value sourced from firmware via the IPC3 channel, is used in arithmetic that calculates expected buffer sizes without overflow protection. On 32-bit platforms, multiplying `num_elems` by struct member sizes can wrap to a small positive value, making the calculated `expected_size` appear smaller than the firmware-reported `cdata->rhdr.hdr.size`. This allows the size check to pass when it should fail, permitting out-of-bounds access in the subsequent `snd_sof_update_control()` call. The fix — adding `check_mul_overflow()` and `check_add_overflow()` — is correct for this line, but it patches a symptom rather than the architectural disease. The deeper problem is that the kernel implicitly trusts `num_elems` as if upstream parsing had validated it, when in fact no documented trust boundary exists between firmware and kernel in the IPC3 interface. This is the same cognitive failure pattern seen in USB descriptor parsing, PCIe config space handling, and GPU command buffer processing — developers assume validation upstream that doesn't exist or isn't enforceable at their call site. What you should examine: First, determine whether `num_elems` receives any validation at the IPC message parsing layer before reaching this function. If it does, audit whether that validation depends on the overflow-protected arithmetic that this fix provides — a circular dependency would make the validation ineffective. Second, survey other IPC3 control handling paths for identical patterns: arithmetic on firmware-provided counts or sizes performed without overflow checks. The SOF codebase has years of similar logic across its IPC3 paths, and this fix addresses one instance of a structural assumption, not the assumption itself. Third, assess the blast radius: if `snd_sof_update_control()` populates shared mixer state, DMA buffers, or cross-channel processing structures, then one corrupted `num_elems` becomes a containment failure for the entire audio subsystem. The low EPSS score reflects the constraint that exploiting this requires compromised firmware — but that risk model deserves scrutiny. SOF firmware blobs are often binary-only, distributed through separate OEM channels, and updated independently of the kernel. The USB ecosystem demonstrated between 2015-2018 that firmware supply chain compromise is a real attack vector even when the local device seems trusted. The kernel-side overflow check is valuable defense-in-depth, but it doesn't sever the connection between firmware compromise and kernel memory corruption; it just adds a speed bump. The separate question of whether firmware blobs are being regenerated with proper message construction is a remediation timeline the CVE metrics don't capture, and in many deployed SOF devices, that timeline may never close.

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