CVE-2026-98835 in Linuxinfo

Summary

by MITRE • 10/18/2026

In the Linux kernel, the following vulnerability has been resolved:

iio: accel: kionix-kx022a: Fix array boundary check

The driver performs a sanity check for an array size, when converting a register value to an array index. The check incorrectly accepts the sizeof(array) as a last index, when last valid index should be sizeof(array) - 1.

Fix the check by bailing out when index >= sizeof(array).

If you want to get best quality of vulnerability data, you may have to visit VulDB.

Analysis

by VulDB Data Team • 10/18/2026

The Linux kernel driver for the Kionix KX022A accelerometer contains a logic error in its input validation routine that can lead to an off-by-one array boundary violation. This specific vulnerability arises during the process of converting raw register values into valid array indices used by the Industrial I/O subsystem. When the driver receives data from the hardware, it must map these values to corresponding entries within internal lookup tables or configuration arrays. To prevent accessing memory outside the allocated bounds, a sanity check is implemented before the index is utilized. However, this validation logic contains a critical flaw where it incorrectly treats the total size of the array as an acceptable last index rather than recognizing that valid indices range from zero up to one less than the array's length.

This type of error is classically categorized under CWE-193 Off-by-One Error in Memory Allocation or Access, which falls within the broader category of CWE-787 Out-of-bounds Write if the data being written exceeds bounds, or CWE-125 Out-of-bounds Read if the driver merely reads from invalid memory locations. The root cause is a failure to properly account for zero-based indexing conventions common in C programming languages. By allowing an index equal to the array size, the code permits access to memory immediately following the allocated buffer. In many kernel contexts, this adjacent memory may contain sensitive data structures or control information, potentially leading to information disclosure if read, or arbitrary code execution if written to, depending on what resides at that specific memory address and how it is utilized by subsequent operations in the driver stack.

From an operational perspective, while this vulnerability exists within a sensor driver which typically requires physical access to modify hardware registers, its exploitation potential depends heavily on the system configuration and privilege levels of processes interacting with the Industrial I/O subsystem. If an attacker can influence the register values read from the device through compromised firmware or malicious peripheral interaction, they might trigger this out-of-bounds access. This aligns with ATT&CK technique T1059 Command and Scripting Interpreter if the vulnerability leads to code execution via subsequent exploitation steps, or T1005 Data from Local System if it results in unauthorized memory reads. The impact ranges from kernel panics causing denial of service to more severe compromises where an attacker gains elevated privileges by corrupting kernel data structures adjacent to the array.

The resolution involves correcting the boundary condition check to ensure that any index greater than or equal to the size of the array is rejected immediately. This simple logical adjustment ensures that only indices within the range of zero to sizeof(array) minus one are processed, thereby preventing access to unallocated memory regions. To mitigate similar risks in other parts of the kernel and third-party drivers, developers should adopt static analysis tools capable of detecting off-by-one errors during the compilation phase. Additionally, enforcing strict bounds checking practices where array sizes are explicitly compared against index values using less-than operators rather than less-than-or-equal-to is a standard best practice recommended by secure coding guidelines such as those from CERT C and MISRA C. Regular auditing of driver code for proper memory management patterns remains essential to maintaining the integrity of the Linux kernel environment.

Responsible

Linux

Reservation

09/25/2026

Disclosure

10/18/2026

Moderation

accepted

EPSS

0.00000

KEV

no

Activities

low

Sources

Interested in the pricing of exploits?

See the underground prices here!