CVE-2026-98238 in Linux
Summary
by MITRE • 10/06/2026
In the Linux kernel, the following vulnerability has been resolved:
net: wwan: t7xx: validate the netif index in t7xx_ccmni_recv_skb()
The netif index carried in the DPMAIF PIT header is five bits wide, but ccmni_inst[] only has room for NIC_DEV_MAX (21) entries.
t7xx_ccmni_recv_skb() indexes the array without a bounds check, so indexes 21 to 31 read past it. The out-of-bounds value lands in the callback table that follows the array, which is never NULL, so the existing !ccmni check does not catch it and the driver dereferences whatever sits there as a struct t7xx_ccmni.
Drop the skb when the index is out of range.
Verified in a QEMU guest with a fault injector setting the netif index to 25: the unpatched driver reads a value past ccmni_inst[],
which lands in the callback table, and dereferences it far enough to queue the skb. With this check the packet is dropped. Well-formed traffic on index 0 is unaffected.
Changes in v2: none.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/06/2026
The Linux kernel driver for the T7xx WWAN device contains a critical out-of-bounds memory access vulnerability within the t7xx_ccmni_recv_skb function, which stems from insufficient validation of input data derived from hardware headers. The specific flaw involves the netif index field carried in the DPMAIF PIT header, which is defined as five bits wide, allowing for values ranging from zero to thirty-one. However, the internal ccmni_inst array used by the driver to manage network interface instances is statically sized with a maximum capacity of twenty-one entries, corresponding to NIC_DEV_MAX. When processing incoming packets, the driver uses this index directly to access elements within the ccmni_inst array without performing any bounds checking. This lack of validation means that if an attacker or malformed hardware provides an index value between twenty-one and thirty-one, the code will read memory locations immediately following the end of the valid array boundary.
The operational impact of this vulnerability is severe due to the specific memory layout surrounding the ccmni_inst array in the kernel's data segment. The out-of-bounds access does not result in a simple null pointer dereference or an immediate segmentation fault, as one might expect from many other buffer over-reads. Instead, the invalid index points into a callback table that resides immediately after the ccmni_inst array in memory. Because this callback table contains function pointers and is never NULL, the existing sanity check within the driver code fails to detect the error. Consequently, the driver proceeds to dereference whatever data structure it interprets as a struct t7xx_ccmni at that invalid location. This leads to undefined behavior, potentially allowing an attacker with access to the device or the ability to inject specific packet headers to trigger arbitrary memory reads, cause kernel panics through corrupted state, or potentially achieve code execution if the misinterpreted data can be controlled to point to valid but malicious function pointers within the callback table.
From a vulnerability classification perspective, this issue is best described as an out-of-bounds read leading to improper access control and potential remote code execution vectors depending on the attack surface. It aligns with CWE-125, which defines Out-of-bounds Read vulnerabilities where software reads data past the end or before the beginning of the intended buffer. Furthermore, in the context of the MITRE ATT&CK framework, this vulnerability facilitates techniques related to privilege escalation and execution through exploitation of driver-level memory corruption, specifically mapping to T1068 Exploitation for Privilege Escalation if an attacker can leverage the arbitrary read or write capabilities implied by such a flaw. The fact that the callback table is involved suggests potential for more complex attacks where the integrity of function pointers could be compromised, although in this specific instance, the primary risk described is the uncontrolled dereference leading to instability or information disclosure via kernel memory leakage.
The resolution implemented involves adding explicit bounds checking within the t7xx_ccmni_recv_skb function before any array indexing occurs. The patch ensures that if the netif index extracted from the DPMAIF PIT header exceeds the maximum valid index of twenty, the incoming socket buffer is immediately dropped rather than processed further. This defensive programming approach effectively neutralizes the vulnerability by preventing access to memory outside the allocated ccmni_inst array. Verification through QEMU emulation with a fault injector confirmed that setting the netif index to values such as twenty-five previously resulted in reading past the array boundary and attempting to queue packets based on corrupted data structures. With the applied fix, these malformed inputs are correctly discarded, while legitimate traffic using valid indices remains unaffected, ensuring no regression in normal operational functionality. This mitigation highlights the importance of strict input validation for all hardware-derived parameters that influence memory access patterns within kernel drivers.