CVE-2026-98204 in Linux
Summary
by MITRE • 10/06/2026
In the Linux kernel, the following vulnerability has been resolved:
Input: rmi_smbus - fix out-of-bounds read in rmi_smb_write_block()
When chunking writes into SMBus blocks in rmi_smb_write_block(), the loop calculates block_len using the original total length (len) instead of the remaining length (cur_len).
If len is greater than 32 bytes (SMB_MAX_COUNT), block_len remains 32 for every iteration, even on the final partial chunk where fewer than 32 bytes remain. This causes smb_block_write() to read 32 bytes from the advanced data buffer pointer, reading past the end of the input buffer.
Fix this by calculating block_len using cur_len and advancing the buffer and address pointers by block_len.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/06/2026
The Linux kernel vulnerability identified in the rmi_smbus driver involves a critical out-of-bounds read within the rmi_smb_write_block function, which is responsible for handling SMBus write operations for RMI4 devices. This flaw stems from an incorrect calculation of block lengths during the chunking process when transmitting data over the SMBus interface. Specifically, the loop logic relies on the original total length parameter rather than tracking the remaining bytes to be written in each iteration. Consequently, if the initial input buffer exceeds thirty-two bytes, which is the maximum count supported by standard SMBus transactions, the function consistently attempts to read exactly thirty-two bytes per block regardless of how much data actually remains at the end of the transmission sequence.
This logical error results in a heap-based or stack-based out-of-bounds read depending on where the input buffer resides in memory. When processing the final partial chunk that contains fewer than thirty-two bytes, the driver advances the pointer and attempts to access memory locations beyond the allocated boundary of the source buffer. Such an operation violates fundamental memory safety principles by reading arbitrary kernel memory contents that were not intended for transmission. While this specific flaw is classified as a read vulnerability rather than a write corruption, it still poses significant security risks including potential information disclosure where sensitive kernel data structures or credentials might be leaked to connected devices or through subsequent processing paths if the invalidly read bytes are utilized further in the stack.
From an industry standards perspective, this issue aligns with CWE-125 which describes out-of-bounds read vulnerabilities that allow attackers to access memory beyond intended boundaries. In terms of attack vectors and tactics, this vulnerability can be mapped to ATT&CK technique T1083 File and Directory Discovery if the leaked data aids in further enumeration, or more broadly under privilege escalation paths where kernel information leaks facilitate exploitation of other weaknesses. The operational impact includes potential system instability due to accessing unmapped memory pages which could trigger a kernel panic, as well as security breaches involving unauthorized access to protected kernel state.
Mitigation strategies primarily involve applying the upstream Linux kernel patch that corrects the loop logic to use the remaining length variable for calculating block sizes and properly advancing pointers based on actual bytes transferred rather than fixed maximum limits. System administrators should ensure their systems are updated with the latest stable kernel versions containing this fix. For environments where immediate patching is not feasible, restricting access to RMI4 devices or disabling SMBus interfaces used by such peripherals can reduce the attack surface until a permanent resolution is deployed in the software stack.