CVE-2026-72261

The patch for CVE-2026-72261 is a textbook example of patching symptoms rather than the disease. The vulnerability lives in the SOF (Sound Open Firmware) IPC3 control handling path, where a memcpy operation trusts a size field (`local_cdata->data->size`) that can be inconsistent with the actual buffer allocation. The fix adds a bounds check at the memcpy site, which is correct defensive coding — but the CVE description explicitly states the size field was 'previously set to an inconsistent value,' and that upstream source of corruption is never identified or patched. That omission is the analytically significant part. The inconsistent state could arise from a race condition in concurrent IPC3 control path writes, from an earlier IPC message that sets size incorrectly due to a separate bug, or from firmware deliberately providing malformed values. Each scenario carries dramatically different implications. If firmware is the source, then CVE-2026-72261 represents a firmware-to-kernel write-what-where primitive that requires no userspace foothold and no exploit sophistication — malformed firmware data triggers the corruption. This would elevate the effective severity well beyond the CVSS 7.8, which assumes a local attackers context. The historical record supports concern: whenever a bounds check gets added without tracing the source of inconsistent state, the corruption mechanism itself remains unfixed and exploitable through other code paths. Multiple CVEs across ARM SMMU, iommu, and GPU subsystems followed this pattern — a second CVE drops 6-18 months later on a different trigger path exercising the same inconsistent state. The 'previously set' language in this CVE implies a producer somewhere in the IPC3 state machine set the size wrong before `snd_sof_update_control()` was even called. Your priorities: first, determine whether the inconsistent size field is triggerable via crafted firmware or IPC messages — if so, treat this as a live write primitive, not a fixed bug. Second, audit all other memcpy operations in the IPC3 control handling path that read `local_cdata->data->size` without validation; the patch hardens one site but leaves the corrupted state itself intact. Third, demand the upstream commit history to trace when `local_cdata->data->size` first diverged — without that lineage, you're managing symptoms. The EPSS score (0.00164) is misleading for environments with untrusted DSP firmware because it doesn't price the firmware-to-kernel attack surface correctly. The real exposure window is the delta between kernel patch availability and firmware patch availability across what are often disjoint supply chains.

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