Intel iwlwifi EUVD-2026-86072

Requires the Intel iwlwifi mld driver with two simultaneous active connections - a BSS (infrastructure) connection AND a NAN (neighbor awareness networking) connection - on the affected host. Exploitation is gated on a firmware error occurring (step 3), after which the reconfig recovery path fails to restore the NAN connection; the firmware error is not something a remote attacker reliably controls. Limiting factors: local vector (AV:L), high attack complexity due to the specific ordering/race between async_handlers_wk and reconfig work (AC:H), the need for a NAN-capable/configured setup, and dependence on a spontaneous or induced FW fault - all of which make deliberate triggering difficult and confine impact to a kernel panic.

This is a use-after-free (dangling pointer) kernel panic in the Intel iwlwifi 'mld' (multi-link device) driver, triggered on the firmware-error/reconfig-failure recovery path. The NVD CVSS of 7.4 (AV:L/AC:H/PR:N/UI:N/C:H/I:H/A:H) overstates real-world risk: the C:H/I:H claims are inflated for what the description makes clear is a kernel panic (availability/DoS outcome), and PR:N is generous given the trigger requires local control over WiFi interface state (bringing up concurrent BSS + NAN connections). No EPSS score, no CISA KEV listing, and no public POC are present in the input - the signals are 'no public exploit identified at time of analysis'. Critically, the root trigger is a spontaneous firmware error (step 3 of the description), which is not directly attacker-controlled; the bug is a reliability/robustness fix (purging stale notifications from a dead FW) rather than a practically weaponizable vector. Conflicting signal to flag: the Tags list this as 'Information Disclosure', but the mechanism (freed link dereferenced → panic) is memory corruption / denial-of-service, not disclosure. Net: real fix worth patching for stability, but low practical exploitation priority.

A local user or a flaky/malicious Intel WiFi adapter induces a firmware error while both a BSS connection and a NAN connection are active. During mac80211 reconfig recovery the NAN restore fails, links are freed, and a queued asynchronous statistics-notification handler dereferences the now-dangling fw_id_to_bss_conf[id], panicking the kernel. No public exploit code is identified; realistic outcome is a denial-of-service crash rather than code execution or data theft.