CVE-2026-72024

This CVE exposes a race condition in network device teardown where list_del() was used instead of list_del_rcu() in the bulk hardware removal path. The bug manifests when an asynchronous transmit completion fires during the narrow window between list deletion and netdevice deallocation, allowing an RCU reader to observe a corrupted list entry. The race window is nanoseconds-scale, which explains the low EPSS despite the high CVSS score. The fix is straightforward: replace list_del() with list_del_rcu() in the affected teardown code path. However, the deeper issue is that the same subsystem contained both the correct and incorrect patterns — the single-interface removal path already used list_del_rcu(), while the bulk hardware teardown path did not. This suggests the bug wasn't a fundamental misunderstanding of RCU requirements but rather inconsistent application of the correct pattern across parallel code paths. For defenders: search your kernel codebases for list_del() calls in any teardown path that executes concurrently with RCU-protected list traversal. The specific trigger here was ieee802154_wake_queue() reading the device list while netdevice deallocation was in progress, but the same pattern could exist in other wireless or network subsystems. Prioritize code paths that handle device removal, interface teardown, or hardware offload cleanup. The presence of correct list_del_rcu() usage elsewhere in the same logical operation is a signal that adjacent paths may have been missed. The low EPSS despite high severity is itself informative: it reflects the narrow race window, not diminished impact. Even probabilistically rare RCU corruption can cause kernel panics or silent data corruption, and the affected code path executes on every packet wake for every device on this stack.

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