CVE-2026-72303

This CVE exposes a fundamental trust boundary failure in how the SOF driver handles IPC4 notification messages. The MODULE_NOTIFICATION handler reads structured data from the notification payload at fixed offsets (bytes and channel information) without first verifying the received buffer is large enough to contain that structure. This is not an algorithmic flaw—it is a missing guard where the kernel accepts firmware-provided size fields as trustworthy input rather than validating them against actual buffer boundaries. The privilege context elevates this from a simple bug to a defensible concern: the handler runs in kernel space, so a buffer over-read can crash the system or corrupt state that downstream audio topology consumers then act on. The CVSS 7.8 appropriately captures the direct impact, but the deeper risk is architectural. When firmware controls both the message content and its declared size, compromised or adversarial firmware doesn't need to exploit a traditional kernel vulnerability—it simply sends a malformed notification that corrupts shared state the kernel will process. This is a fundamentally different threat model than remote network exploitation, and it explains why the EPSS score remains low: triggering this requires a firmware compromise first, not an external attacker. What should concern you is the pattern's lineage. The SOF IPC3 path accumulated multiple CVEs over five years where length validation was retroactively added to handlers that initially trusted firmware-sourced size fields. When IPC4 shipped as the modernization path, implementers inherited the mental model—not explicit comments, but the assumption that firmware-provided sizes are advisory rather than hostile input. One patch in one MODULE_NOTIFICATION handler doesn't change that habit across the codebase. Audit your deployments for other IPC4 message handlers. Any path that reads structured fields from notification or command payloads based on size information from firmware is a candidate for the same gap. The fix here is likely a simple length check before structured access, but the systemic exposure is in how your audio driver architecture treats firmware as a trusted peer rather than an unvalidated input source. If similar patterns exist in GPU firmware interfaces, ACPI handling, or USB descriptor parsing in your kernel tree, this CVE should prompt a broader review—not because this one instance is critical, but because the underlying assumption is load-bearing across multiple subsystems.

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