CVE-2026-93149 in Linux
Summary
by MITRE • 09/18/2026
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211_hwsim: avoid NULL skb in stop queue drain
mac80211_hwsim_stop() drops any frames left in data->pending. The loop currently checks skb_queue_empty() and then dequeues separately.
That split is racy with TX status handling, which can remove a pending frame under the queue lock. If the last entry is removed after the empty check, skb_dequeue() returns NULL and the stop path passes that NULL skb to ieee80211_free_txskb().
Use skb_dequeue() as the loop condition instead. The dequeue result is the object that stop owns and frees, and a concurrent status completion that empties the queue simply makes the loop terminate.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified in the Linux kernel within the mac80211_hwsim subsystem represents a classic race condition arising from improper synchronization between data structure inspection and modification operations. Specifically, the issue resides in the mac80211_hwsim_stop function which is responsible for draining any frames remaining in the pending transmission queue when the virtual interface is being stopped or removed. The original implementation employed a pattern where it first checked if the queue was empty using skb_queue_empty() and subsequently attempted to dequeue and free each frame individually. This separation of checking and acting creates a critical window of vulnerability known as check-then-act, which is inherently unsafe in concurrent environments without holding appropriate locks throughout both phases.
The core technical flaw involves a race condition with the transmission status handling mechanism. In wireless networking stacks like mac80211, transmitted frames are tracked to report their completion status back to upper layers or drivers. This TX status processing occurs under its own locking context and can remove pending frames from the queue independently of the stop operation. If the last frame in the data->pending queue is removed by a concurrent TX status handler immediately after the mac80211_hwsim_stop function checks that the queue is not empty but before it attempts to dequeue, the subsequent call to skb_dequeue() will return NULL because the queue has effectively become empty due to the external removal. Passing this NULL pointer directly to ieee80211_free_txskb results in a null pointer dereference, which typically causes a kernel panic or system crash depending on the specific architecture and configuration of the Linux kernel.
From an operational impact perspective, this vulnerability allows for local denial of service attacks if triggered by user-space applications that can manipulate virtual Wi-Fi interfaces managed by hwsim. Since mac80211_hwsim is often used for testing and simulation purposes but remains part of the mainline kernel codebase, it exposes systems to instability during interface teardown sequences under high concurrency or specific timing conditions. The severity lies in the fact that this does not require elevated privileges beyond those needed to create or destroy network interfaces, making it accessible to unprivileged users who can trigger the race condition through rapid creation and destruction of virtual Wi-Fi devices.
The remediation strategy implemented addresses the root cause by restructuring the loop logic to use skb_dequeue() as the primary loop condition rather than a separate empty check. This approach ensures that each iteration atomically retrieves an object from the queue, guaranteeing that if the function proceeds to free the returned pointer, it is valid and not NULL. If a concurrent TX status completion empties the queue between iterations, the dequeue operation simply returns NULL, causing the loop to terminate gracefully without attempting to dereference or free invalid memory. This pattern aligns with established best practices for handling linked lists in kernel space where elements may be removed by multiple threads concurrently.
This vulnerability maps directly to CWE-362, which describes concurrent execution using shared resources with improper synchronization. The specific mechanism of checking a condition and then acting on it without holding the lock is a textbook example of this weakness. Furthermore, from an offensive security perspective such as MITRE ATT&CK, this could be categorized under T1059 Command and Scripting Interpreter if exploited via scriptable interface manipulation or more broadly within system exploitation techniques that target kernel memory corruption leading to denial of service. The fix exemplifies the importance of atomic operations in multi-threaded environments and reinforces the need for rigorous lock ordering and scope management when dealing with shared data structures like packet buffers in network subsystems.