CVE-2026-74340

This CVE exposes a trust boundary failure that receives less attention than it deserves: the kernel's wcn36xx driver implicitly trusts firmware-supplied data as a loop bound. When processing a PRINT_REG_INFO indication, the driver extracts rsp->count from the firmware response and uses it to iterate through rsp->regs[] without validating that the declared count aligns with the actual message length. The result is a heap out-of-bounds read where the read size is directly controllable by the wireless firmware. The CVSS 8.1 reflects the potential severity, but the EPSS of 0.00277 indicates this isn't being actively exploited. That gap between CVSS and EPSS deserves scrutiny. The wcn36xx driver supports WCN3660 and WCN3680 — hardware that has been end-of-life for years. The firmware runs on a dedicated co-processor with significant autonomy, yet drivers treat it like hardware rather than the software actor it actually is. This cognitive mismatch is the root cause: developers optimize for making wifi work, not for defending against a potentially compromised coprocessor. The immediate fix — validating the firmware-supplied count against message length — is correct and necessary. But this vulnerability class recurs every 12-18 months across USB, PCI, display, and now wireless drivers. Each CVE gets a local bounds-check patch while the architectural condition persists: the kernel driver model has no mechanism enforcing that hardware interfaces validate their own assumptions. Static analysis tooling doesn't catch this pattern at scale, and no review standard flags implicit trust in device-provided counts. The deeper question is whether this represents a practical exploitation path or a theoretical defense-in-depth gap. For active hardware with ongoing firmware updates, the firmware-as-trusted-actor model may be acceptable. For EOL hardware — where the driver persists in kernels but the firmware will never be patched — this represents unquantified risk sitting in the sediment. The compound exploit requirement (firmware bug producing a malicious count plus driver failure to validate it) further constrains practical exploitation. Analysts should treat this as a signal to audit other wcn36xx indication handlers for similar implicit trust assumptions, and more broadly, examine wireless drivers interacting with autonomous coprocessors. The patch closes this instance; the ergonomic problem ensures analogous gaps exist elsewhere.

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