Linux Kernel EUVD-2026-86180

Requires a system running the Linux iwlwifi MVM driver with an Intel WiFi adapter, AND the ability to deliver a malformed TX_CMD firmware-to-host response whose frame_count does not match the response buffer length (e.g., compromised or malicious device firmware, or a tampered/substituted adapter). Exploitation is fundamentally limited by the fact that TX_CMD responses originate from the WiFi firmware, not from over-the-air frames, so a remote or merely adjacent radio attacker cannot craft them in a default, uncompromised configuration; this is why the fix is primarily hardening against a malicious firmware trust boundary.

The input CVSS is 8.8 (AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), but this vector significantly overstates real-world risk and conflicts with the technical description. The bug is a missing minimum-length check in the iwlwifi MVM driver's TX_CMD response parser: it trusts a firmware-supplied frame_count to walk status entries and read the trailing SCD SSN without validating the runtime layout against the actual buffer length. TX_CMD responses are firmware-to-host control messages, not frames an attacker crafts over the air - so the AV:A/PR:N/AC:L rating is questionable. Realistically an adversary needs a compromised/malicious WiFi adapter or firmware image to deliver a malformed response, which is an OOB read yielding kernel-memory disclosure or a crash (DoS), not a clean C:H/I:H/A:H triple. There is no EPSS score, no CISA KEV listing, and no public POC - exploitation status is 'no public exploit identified at time of analysis.' Signals conflict: high nominal CVSS vs. a firmware-gated hardening fix with no exploitation evidence. This is a low-priority defensive hardening patch for most environments, not an urgent remotely-exploitable flaw; the CVSS-implied severity should be treated with skepticism and the vector verified against the driver's actual firmware trust boundary.

An attacker who controls the WiFi adapter's firmware (malicious/compromised device, or a substituted/tampered adapter) sends a TX_CMD response with a frame_count value inconsistent with the buffer length. The iwlwifi MVM driver walks status entries and reads the trailing SCD SSN past the end of the response buffer, disclosing adjacent kernel memory or crashing the kernel. No public POC or in-the-wild exploitation is known.