CVE-2026-98407 in Linux
Summary
by MITRE • 10/14/2026
In the Linux kernel, the following vulnerability has been resolved:
wifi: rsi: fix heap OOB write on key removal
When a key is removed (data == NULL), rsi_hal_load_key() runs:
memset(&set_key[FRAME_DESC_SZ], 0, frame_len - FRAME_DESC_SZ);
set_key is a struct rsi_set_key *, so the subscript is scaled by sizeof(struct rsi_set_key) (160 bytes): &set_key[FRAME_DESC_SZ] is
skb->data + 2560, and the memset writes 144 zero bytes starting 2.4KB past the end of the 160-byte skb data buffer, corrupting unrelated heap objects. The intended byte offset would have been (u8 *)set_key + FRAME_DESC_SZ.
The write fires on every DISABLE_KEY callback, so plain disconnects, roams and interface teardowns trigger it on real networks.
The memset is redundant: the whole buffer is zeroed right after allocation, so the frame sent to the device is byte-identical without it. Drop the else branch; normal operation is unaffected.
Discovered by Atuin - Automated Vulnerability Discovery Engine.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/14/2026
A critical heap-based out-of-bounds write vulnerability has been identified within the Linux kernel's RSI wireless driver, specifically affecting the rsi_hal_load_key function during key removal operations. This flaw stems from a fundamental misunderstanding of pointer arithmetic and memory layout in C programming. When a cryptographic key is removed by passing NULL as the data parameter, the code attempts to clear specific fields within a set_key structure using memset. However, the implementation incorrectly treats the set_key variable as an array rather than a single struct instance. Consequently, the subscript FRAME_DESC_SZ is scaled by the size of the rsi_set_key structure, which is 160 bytes. This results in calculating an offset that is significantly larger than intended, leading to memory writes far beyond the allocated buffer boundaries.
The technical root cause lies in the expression &set_key[FRAME_DESC_SZ]. In C, array indexing multiplies the index by the size of the element type. Since set_key is a pointer to a struct rsi_set_key, adding FRAME_DESC_SZ (which equals 16) results in an offset of 2560 bytes from the base address of set_key. The intended operation was likely to access a byte offset within the single structure instance, which should have been calculated as &set_key + FRAME_DESC_SZ or by casting set_key to a uint8_t pointer first. Instead, the code writes 144 zero bytes starting at an address that is approximately two and a half kilobytes past the end of the associated socket buffer data area. This constitutes a classic heap overflow where adjacent memory allocations are corrupted with null values, potentially overwriting critical metadata or other object headers within the kernel's slab allocator.
The operational impact of this vulnerability is severe due to its high trigger frequency. The flawed code path executes on every DISABLE_KEY callback, which occurs during routine network operations such as plain disconnections, roaming between access points, and interface teardowns. This means that any user or application performing standard wireless connectivity tasks can inadvertently corrupt kernel heap memory. Such corruption can lead to unpredictable system behavior, including crashes, denial of service conditions where the network stack becomes unstable, or potentially exploitable scenarios if an attacker can influence the state of adjacent heap objects. The vulnerability affects real-world networks and is not limited to specific edge cases involving malformed packets but rather normal operational flows.
From a classification perspective, this issue aligns with CWE-787: Out-of-bounds Write, as it involves writing data beyond the allocated buffer boundary into kernel memory space. It also relates to CWE-120: Buffer Copy without Checking Size of Input in terms of the underlying logic error that fails to respect memory boundaries during pointer manipulation. In the context of the MITRE ATT&CK framework for Linux systems, this vulnerability could be leveraged as part of a privilege escalation attack vector if an unprivileged user can trigger key removal operations repeatedly to corrupt kernel structures leading to arbitrary code execution or denial of service against local services.
The resolution involves removing the redundant memset operation entirely rather than correcting the pointer arithmetic. Analysis revealed that the entire buffer is already zeroed immediately after allocation, rendering the subsequent clearing of specific fields unnecessary for maintaining byte-identical frames sent to the device hardware. By dropping this else branch, the vulnerability is eliminated without altering normal operational behavior or introducing new complexity into the driver's memory management logic. This fix ensures that key removal operations no longer trigger out-of-bounds writes while preserving the functional integrity of wireless connectivity features.
To mitigate similar risks in other drivers and kernel subsystems, developers should adhere to strict pointer arithmetic guidelines, ensuring explicit casting when performing byte-level offsets on struct pointers rather than relying on array indexing semantics which scale by element size. Regular static analysis using tools like Atuin can help identify such logical errors before they reach production kernels. Additionally, enabling Kernel Hardening options and utilizing Address Sanitizers during development phases can provide early detection of heap corruption issues. Maintaining clear separation between buffer management logic and hardware-specific command construction is also recommended to prevent confusion regarding memory layout expectations in wireless drivers.