CVE-2026-98422 in Linux
Summary
by MITRE • 10/14/2026
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: reset the AP_VLAN tailroom counter on ifdown
On ifup, AP_VLAN interfaces get crypto_tx_tailroom_needed_cnt from the AP interface, but it's never decremented again unless the AP is also brought down. Thus, bringing the same AP_VLAN up again will increment the counter again and eventually hit the sanity check:
WARN_ON_ONCE(sdata->crypto_tx_tailroom_needed_cnt != master->crypto_tx_tailroom_needed_cnt);
Reset it on ifdown to avoid that.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/14/2026
The Linux kernel contains a logic error within the mac80211 wireless subsystem related to the management of AP_VLAN interfaces and their associated cryptographic tail room counters. This vulnerability arises from an asymmetry in how reference counts or state variables are managed during interface lifecycle events, specifically when dealing with virtual LAN interfaces attached to access point master interfaces. The core issue involves the crypto_tx_tailroom_needed_cnt variable, which tracks the number of pending encryption operations requiring specific buffer space allocation for cryptographic headers and trailers. When an AP_VLAN interface is brought up using standard network configuration tools such as ip link or ifup, it inherits this counter value from its parent AP master interface to ensure that sufficient tail room is reserved in packet buffers for subsequent encryption processes. This inheritance mechanism is critical for maintaining data integrity during wireless transmission where cryptographic overhead must be accounted for before the frame leaves the kernel space.
However, a significant flaw exists in the teardown procedure of these virtual interfaces. While the counter is correctly incremented or inherited upon interface activation, it fails to be decremented when the AP_VLAN interface is brought down using ifdown commands. This omission means that the master AP interface retains an inflated count of required tail room even after the dependent VLAN interface has been deactivated and removed from active use. The kernel includes a sanity check implemented via WARN_ON_ONCE which compares the crypto_tx_tailroom_needed_cnt of the slave interface against its master counterpart to ensure consistency in state management across the virtual network stack. Because the counter is never reset on teardown, subsequent attempts to bring up another AP_VLAN interface or even reuse the same configuration will cause the local counter to increment again based on an already inflated baseline from the master.
This accumulation of un-decremented counters leads directly to a violation of the internal consistency checks within the mac80211 subsystem. As the cycle of bringing interfaces up and down repeats, the discrepancy between the slave's expected state and the master's accumulated state grows until it triggers the WARN_ON_ONCE condition. While this specific manifestation primarily results in kernel warnings that can clutter system logs and potentially indicate deeper instability, such logic errors often serve as precursors to more severe issues including memory corruption or denial of service conditions if the counter values eventually overflow or cause incorrect buffer allocations during packet processing. The lack of proper state cleanup represents a failure in resource management principles where allocated resources are not released upon deallocation, leading to state drift and eventual functional degradation of the wireless networking stack.
From a classification perspective, this vulnerability aligns with CWE-401 Missing Release of Resource after Effective Lifetime, as the system fails to properly release or reset internal accounting structures associated with network interfaces when they are no longer in use. It also relates to CWE-697 Incorrect Comparison, given that the sanity check relies on accurate state synchronization between parent and child interface objects which is broken by this oversight. In terms of attack vectors, while primarily a stability issue rather than an exploitable security flaw for remote code execution, it impacts availability by potentially causing kernel warnings or instability in high-churn environments where virtual interfaces are frequently created and destroyed. This falls under the ATT&CK technique T1496 Resource Hijacking if viewed through the lens of resource exhaustion, although more accurately it is a reliability defect affecting system integrity rather than malicious exploitation.
To mitigate this vulnerability, kernel developers have implemented a fix that explicitly resets the crypto_tx_tailroom_needed_cnt counter to zero or its baseline value when an AP_VLAN interface is brought down. This ensures that subsequent activations start with a clean state relative to the master interface's current requirements without carrying over stale counts from previous sessions. System administrators and users relying on dynamic virtual LAN configurations should ensure they are running kernel versions patched with this correction. For environments where such interfaces are dynamically provisioned, monitoring for repeated WARN_ON_ONCE messages in dmesg output can serve as an indicator of whether the system is operating under unpatched conditions that may lead to progressive state corruption and eventual network stack instability.