CVE-2026-99134 in Linux
Summary
by MITRE • 10/28/2026
In the Linux kernel, the following vulnerability has been resolved:
mac802154: fix data race and NULL deref on local->assoc_dev
local->assoc_dev is shared between the association path and the association-response worker without common synchronization.
mac802154_perform_association() stores the coordinator pointer and waits for a response. Its timeout and error paths clear the pointer and return to mac802154_associate(), which may then free the coordinator object. Meanwhile, mac802154_rx_mac_cmd_worker() may observe the associating bit and enter mac802154_process_association_resp(), which dereferences assoc_dev.
The worker's bit test and the handler's pointer dereference are not atomic with respect to cleanup. Cleanup can clear assoc_dev between them, causing a NULL dereference, or free the coordinator while the response handler still uses the pointer.
The recorded result is exposed to the same window. assoc_status and assoc_addr are written by the handler but read by the association path while the associating bit is still set, so a second response for the same request - a malicious one, for instance - can replace them between those reads and leave the caller with an incoherent status and address pair.
The response handler only needs the coordinator extended address. Replace assoc_dev with a cached address, removing the pointer lifetime dependency. Protect the cached address and the associating bit with a dedicated spinlock. A READ_ONCE()/WRITE_ONCE() pair would not guarantee an atomic __le64 access on all 32-bit architectures.
wpan_dev->association_lock cannot be reused here: nl802154_associate() holds it across rdev_associate(), hence for the whole of mac802154_perform_association() including the wait for the response. A response handler taking that lock would only get it once the association has already given up.
Reset the completion, publish the cached address, and set the associating bit while holding the lock. The response handler takes the lock, rechecks the bit and the cached address, records the response, clears the bit, and only then completes the waiter. Thus cleanup cannot pass the handler between its state check and completion, and the cached 64-bit value cannot tear.
The handler clears the bit before completing, not the woken waiter: otherwise complete() is issued under the lock and a second (e.g. malicious) response can reacquire it before the waiter and replace the result. So a wait that returns success implies the bit is already clear, and the success and negative-response paths return directly. The transmit-error and timeout paths still clear it under assoc_lock, which serializes any racing response against the cleanup while the call returns the error it already selected. Both paths snapshot assoc_status and assoc_addr under the same lock.
Both users run in process context, so a plain spinlock is sufficient. The lock is not held while waiting for the completion.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/28/2026
The Linux kernel vulnerability identified within the mac802154 subsystem represents a critical concurrency flaw involving data races and potential null pointer dereferences during the IEEE 802.15.4 association process. This issue stems from improper synchronization of shared state between the primary association path, which initiates the connection request, and the asynchronous worker responsible for processing incoming association responses. Specifically, the local structure member assoc_dev is accessed by both contexts without adequate mutual exclusion mechanisms. The core technical flaw lies in the lack of atomicity when checking flags and dereferencing pointers. When mac802154_perform_association stores a coordinator pointer and waits for a response, it relies on timeout or error paths to clear this pointer before returning control to the caller who may subsequently free the associated object. Concurrently, the worker function mac802154_rx_mac_cmd_worker checks an associating bit and proceeds to dereference assoc_dev in its handler. Because these operations are not synchronized, a race condition emerges where cleanup code can clear or free the pointer between the worker's flag check and its subsequent memory access, leading directly to null pointer dereferences or use-after-free scenarios that compromise system stability and security.
Beyond simple memory safety issues, this vulnerability introduces logical inconsistencies due to unsynchronized reads and writes of status variables. The fields assoc_status and assoc_addr are written by the response handler but read by the association path while the associating bit remains set. This window allows for a scenario where a second response packet, potentially crafted maliciously, can overwrite these values between the time they are read by one context and used by another. Such race conditions result in incoherent state pairs where the status does not match the address, leading to unpredictable behavior or potential exploitation vectors that could bypass security controls relying on accurate association data integrity. The absence of atomic operations for 64-bit values like __le64 on certain 32-bit architectures further exacerbates this risk, as standard read-write sequences may result in torn reads where half the value is from one update and half from another, rendering the resulting address or status meaningless.
The remediation strategy involves a fundamental restructuring of how synchronization primitives are applied to this subsystem. The solution replaces the direct pointer dependency on assoc_dev with a cached extended address field, thereby eliminating the lifetime management complexity associated with dynamically allocated coordinator objects during the response phase. To protect both this cached address and the associating bit, a dedicated spinlock is introduced. This approach ensures that all state transitions are atomic relative to each other. The implementation details require careful ordering: the association path must reset completions, publish the new cached address, and set the associating bit while holding the lock. Conversely, the response handler acquires this same lock, re-verifies both the bit status and the cached address validity before proceeding. This double-check pattern prevents stale data processing. Crucially, the handler clears the associating bit only after recording the response but before signaling completion to avoid a scenario where a malicious second response could reacquire the lock while the waiter is still pending, thereby overwriting legitimate results.
From an operational impact perspective, this vulnerability affects systems relying on IEEE 802.15.4 wireless personal area networks for critical IoT communications or industrial control applications. A successful exploitation could lead to kernel panics due to null pointer dereferences, causing denial of service conditions in networked environments. Furthermore, the ability to inject coherent but malicious association responses allows an attacker to manipulate device state, potentially facilitating unauthorized access to network resources or disrupting communication flows by forcing devices into invalid states. The fix ensures that cleanup operations are serialized against response handling, guaranteeing that no race condition can occur between state checks and completion signals. By keeping the lock held only during critical sections and not during the wait for responses, the solution maintains system performance while ensuring strict consistency of shared data structures across process contexts.
This vulnerability aligns with Common Weakness Enumeration categories such as CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization (Race Condition) and CWE-476 NULL Pointer Dereference. In terms of MITRE ATT&CK mapping, the exploitation vector relates to techniques involving resource manipulation during initialization or state transitions, potentially falling under adversary actions that disrupt service availability or manipulate system configuration through race conditions in kernel-space drivers. The resolution emphasizes robust synchronization patterns appropriate for process-context execution, utilizing spinlocks where interrupt context is not involved, and ensuring atomicity of 64-bit operations on architectures lacking native support. This case highlights the necessity of rigorous lock ordering and state validation in asynchronous network driver development to prevent subtle concurrency bugs that can lead to significant security and stability failures.