CVE-2026-80948

What it actually does

A kernel memory leak in the Intel iwlwifi DVM (legacy) wireless driver during op-mode start. After EEPROM data is parsed successfully, certain error paths free nvm_data but skip freeing the EEPROM blob, leaving unreclaimed kernel allocations tied to driver bring-up. Repeated hits on those paths can grow unreclaimed slab/heap usage and contribute to memory pressure or instability in the wireless stack. This is a resource-management defect, not a memory-corruption primitive.

Why it matters to the business

Operational risk is low for most organizations. The flaw is a denial-of-service class leak on older Intel DVM Wi-Fi hardware, has a very low and stable EPSS (~0.002), is not in CISA KEV, has no known ransomware use, and has no reported in-the-wild exploitation about 20 days after publication. Confidentiality and integrity are not affected. Residual concern is limited to Linux systems with legacy Intel DVM adapters that repeatedly fail driver start, where unreclaimed kernel memory could degrade availability. Treat as routine kernel maintenance rather than an emergency.

How an attack unfolds

This defect is not a remote code-execution or network-facing Wi-Fi attack. It is an error-path leak during iwlwifi DVM start after EEPROM parse. A local actor, or a condition that repeatedly forces probe/start to fail after that parse (for example, repeated module reloads or device re-init under error), could accumulate leaked EEPROM-blob allocations and pressure kernel memory. There are no named threat actors, no KEV listing, and exploit maturity is none. Practical abuse is constrained to systems that actually load the DVM op-mode on supported Intel hardware and can induce those post-parse failures.

How to fix it

Apply a Linux kernel update that includes the iwlwifi DVM fix reordering error-handling labels so out_free_eeprom falls through to out_free_eeprom_blob and the EEPROM blob is always freed on those paths. Prefer the vendor or distro kernel that backports this change for your running series. If you cannot patch immediately, avoid repeatedly reloading iwlwifi or re-probing DVM devices on failure, and restrict module load/unload to administrators. Systems without Intel DVM-generation Wi-Fi (most modern Intel MVM adapters) are not in the affected path. No package-specific fixed versions were supplied with this record; track distro kernel changelogs for the iwlwifi DVM memory-leak fix.

How to confirm the fix worked

Confirm the running kernel changelog or patch list includes the iwlwifi DVM error-label reordering for iwl_op_mode_dvm_start(). After upgrade, reload or reprobe the adapter under the same failure conditions that previously leaked and watch kmemleak or slab growth for unreclaimed EEPROM-blob sized objects. On hosts without DVM hardware, validation is confirming iwlwifi DVM is not loaded (MVM-only or no Intel Wi-Fi). Do not use exploit PoCs; use vendor kernel packages and standard leak detectors.

Typical attack path

1. Identify a Linux host using the legacy Intel iwlwifi DVM op-mode rather than MVM.
2. Cause iwl_op_mode_dvm_start() to run (driver load, device probe, or re-init).
3. Induce an error after EEPROM parse so the leaky cleanup path is taken.
4. Repeat start/error cycles so unreclaimed EEPROM-blob memory accumulates.
5. Observe kernel memory pressure or reduced availability of the wireless/host stack.

How to detect it

Look for evidence of repeated iwlwifi DVM start failures and unreclaimed kernel allocations, not for a network payload. Review kernel logs around iwlwifi/DVM probe and EEPROM handling, kmemleak reports of unreferenced objects allocated during iwl_op_mode_dvm_start, and slab/kmalloc growth coincident with module load or device re-init. There is no public exploit, no named actor TTPs, and no ransomware association, so treat isolated DVM init errors as reliability noise unless leak detectors show accumulating EEPROM-blob sized blocks after those errors. Compare pre- and post-patch kmemleak output if a host was failing DVM start.

• iwl_op_mode_dvm_start
• iwlwifi.*dvm
• out_free_eeprom
• eeprom_blob
• kmemleak:.*iwl
• modprobe iwlwifi
• rmmod iwlwifi

What your security team should do

• Patch Linux kernels on hosts that load iwlwifi DVM as part of normal cycle; this is not an emergency KEV item.
• Inventory whether any fleet systems still use legacy Intel DVM Wi-Fi versus modern MVM devices.
• Prioritize only those DVM hosts; skip crash-patching of MVM-only or non-Intel Wi-Fi estates.
• Restrict unprivileged ability to reload wireless modules or reset the device to reduce leak amplification.
• Track distro advisories for the exact backported kernel version; EPSS is stable and low, so schedule with ordinary kernel updates.
• Do not allocate incident-response resources unless kmemleak or unexplained slab growth is already correlating with iwlwifi DVM start failures.