Description

In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mld: purge async notifications upon nic error This fixes a kernel panic in reconfig failure: 1. we have a BSS connection 2. we have a NAN connection 3. FW error occurs 4. reconfig restores the BSS connection 5. however, restoring the NAN connection fails due to a FW error. 6. erroneously, ieee80211_handle_reconfig_failure is called and marks all interfaces as not-in-driver (will be fixed in a different patch). 7. mac80211 frees the links of the BSS connection but doesn't tell the driver about that, as it thinks that this vif is not in the driver. 8. in ieee80211_stop_device, *ALL* wiphy works are getting flushed (erroneously?) 9. Therefore, async_handlers_wk is being executed, processing the statistics notification that was received after we restored the BSS connection. 10. the notification handler dereferences fw_id_to_bss_conf[id], which is now a dangling pointer, as mac80211 already freed this link in (7). 11. On the first access to one of the links fields, we panic. While this can and should be fixed by removing the call to ieee80211_handle_reconfig_failure in (6), it is also not a good idea to carry and maybe handle notifications from a dead FW. We do purge the notifications when we stop the FW, but in reconfig failure we stop the FW too late, after the notifications are processed. In addition, async_handlers_wk can always be scheduled before the reconfig work. Purge the notifications immediately when transport notifies about a nic error.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.4",
  "pubDate": "2026-09-24T17:17:24.547Z",
  "pubdate": "2026-09-24T17:17:24.547Z",
  "executiveSummary": "A use-after-free vulnerability exists in the Linux kernel's iwlwifi driver, specifically within the Multi-Link Device (MLD) subsystem. The flaw is triggered during a firmware (FW) error and subsequent unsuccessful reconfig procedure.\nThe vulnerability occurs when asynchronous notifications are processed after a BSS connection link has been prematurely freed by the mac80211 layer, but before the driver has effectively purged pending work items.\nThe primary impact is a kernel panic, leading to a system denial-of-service. This vulnerability affects wireless subsystems utilizing the iwlwifi driver for MLD-capable NICs.\nThe risk is categorized as high for systems where firmware instability or hardware errors occur, as an attacker or an unstable environment could induce these conditions to crash the kernel.\nExploitation does not require external network interaction but depends on a specific sequence of events triggered by a firmware error state, leading to the dereferencing of a dangling pointer in the fw_id_to_bss_conf array.",
  "technicalDetails": "The root cause of this vulnerability is a race condition between asynchronous notification processing and link teardown during a reconfig failure recovery flow within the iwlwifi MLD stack.\nThe vulnerability manifests during the following sequence: 1) A firmware error is detected, triggering a recovery/reconfig process. 2) During the partial recovery, a BSS connection is successfully restored, but a subsequent NAN connection restoration fails. 3) The failure of the NAN restoration triggers ieee80211_handle_reconfig_failure, which incorrectly flags interfaces as not-in-driver. 4) Consequently, mac80211 frees the links associated with the BSS connection; however, due to the incorrect state flag, the iwlwifi driver is not properly notified to release its internal references.\nWhen ieee80211_stop_device is invoked, it flushes all wiphy work queues, including the async_handlers_wk. This work queue processes stale statistics notifications that were received after the initial BSS restoration but before the firmware error fully manifested.\nThe notification handler proceeds to dereference fw_id_to_bss_conf[id]. Since mac80211 has already deallocated the link structures, fw_id_to_bss_conf[id] becomes a dangling pointer. The resulting access causes an immediate kernel panic as the system attempts to operate on memory that is no longer valid or has been reclaimed by the slab allocator.\nThe failure to purge async_handlers_wk immediately upon the transport layer reporting a NIC error allows this stale notification to remain in the queue, creating a window of opportunity for the use-after-free condition to be met. The race condition is exacerbated because the async_handlers_wk can be scheduled and executed concurrently with the cleanup logic in the reconfig failure path, ensuring the handler operates on the stale configuration array before the driver has safely synchronized its state."
}