CVE-2026-68326

The vulnerability in mwifiex is an out-of-bounds read where the driver trusts a firmware-supplied length field without validating it against the actual receive buffer. That sounds like a standard buffer overflow, but the real significance is the trust boundary it violates: not remote code execution, not a compromised process, but firmware running on peripheral silicon. A malicious or malfunctioning USB/SDIO/PCIE device speaking the mwifiex protocol can trigger slab-out-of-bounds reads in kernel memory without any other exploit primitives. The patch validates `event->len` against `event_body[MAX_EVENT_SIZE]` rather than relying on upstream transport checks. This matters because different transports store events inconsistently — USB strips headers, SDIO doesn't, PCIe pulls them — so the validation must happen at the common buffer anchor point, not at the generic event receive path. What matters practically: audit other mwifiex event handlers for the same pattern where device-supplied length fields are trusted without bounds checking against their destination buffers. More broadly, this CVE is one instance of a systemic class. The firmware-to-host trust boundary is endemic across USB, Bluetooth, storage, and networking controllers. The EPSS of 0.00257 reflects rarity of the specific hardware, not the prevalence of the pattern. Drivers that assume firmware is a trustworthy oracle and process device-supplied lengths without validation at the canonical boundary are carrying the same risk at varying severity levels. Note that mwifiex maintenance has effectively consolidated to a single vendor, and the institutional knowledge mapping how different transports handle event headers is fragile. Future auditors looking for the commit-119585281617 class of fixes will face knowledge gaps if this driver continues to see minimal stewardship.

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