CVE-2026-72446

This vulnerability in the Qualcomm audio stack exposes a dangerous pattern: developers apply guards to 'enable' operations (perceived as risky because they allocate state) while leaving 'disable' paths unprotected under the assumption that cleanup is inherently safe. The bug exists because `.info` is allocated lazily on first enable, creating two distinct NULL states for the disable handler to navigate — 'never allocated' and 'allocated but with invalid index' — but the disable path was never updated when lazy allocation was introduced. The result is two different failure modes with wildly different blast profiles. The 'never enabled' path triggers a kernel oops — loud and crashy. The 'enabled once, wrong interface on disable' path triggers a silent out-of-bounds 4-byte write that clears pipe fields without crashing. The latter is your exploit path: no crash means the system keeps running while kernel slab state is quietly corrupted. The AF_QIPCRTR unprivileged local access vector means this is reachable from userspace without privileges, compounding the risk. The one-line fix (adding the same NULL guard that exists on enable) is deceptively simple — its simplicity is evidence of how invisible the asymmetry was, not evidence that it should have been caught. The real vulnerability isn't the missing check; it's the architectural assumption that disable operations don't require equivalent rigor. Treat paired operations like enable/disable as a single security contract. When one side gains a new invariant (like lazy allocation), audit the inverse path immediately. The existence of a guard on one branch should be treated as a flag that the other branch needs equivalent scrutiny, not as evidence that the pair has been reviewed.

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