CVE-2026-90314 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
remoteproc: fix OOB read via signed offset in rsc_table_for_each_entry()
table->offset[i] is a u32 from firmware, but was stored into a signed
int. A crafted offset like 0xFFFFFFF0 becomes -16, placing hdr 16 bytes before the table buffer. The subsequent avail check was bypassed because the negative int was promoted to a large size_t in the expression "table_sz - offset - sizeof(*hdr)", yielding a large positive avail and letting the out-of-bounds hdr->type read proceed undetected.
Store the offset as u32 and validate it with unsigned comparisons before any pointer arithmetic.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel's remoteproc subsystem contains a critical memory safety vulnerability arising from improper type handling during resource table parsing operations. Specifically, within the rsc_table_for_each_entry function, an offset value extracted from firmware data is defined as an unsigned 32-bit integer but is incorrectly stored in a signed integer variable. This discrepancy creates a classic integer conversion flaw where large unsigned values are misinterpreted as negative numbers due to two's complement representation rules. When a crafted or maliciously constructed resource table provides an offset such as 0xFFFFFFF0, the system interprets this value as -16 rather than its intended positive magnitude.
This signed interpretation leads directly to out-of-bounds memory access through pointer arithmetic errors. The subsequent availability check calculates the remaining buffer space using the expression table_sz minus offset minus sizeof header structure. Because the negative integer is promoted to a large unsigned size_t during this calculation, the result becomes an erroneously large positive number representing available bytes. This bypasses boundary validation logic that would normally prevent access beyond the allocated memory region. Consequently, the kernel proceeds to read the type field of a resource entry located 16 bytes before the start of the table buffer, resulting in an out-of-bounds read operation.
The operational impact of this vulnerability allows for potential information disclosure or system instability depending on what data resides immediately prior to the allocated table region. An attacker with the ability to supply firmware images containing crafted resource tables can exploit this flaw to leak kernel memory contents into user space or trigger a general protection fault leading to denial of service conditions. This issue highlights the dangers of implicit type conversions in low-level system code where precise boundary checks are essential for maintaining memory integrity and preventing unauthorized data access.
To mitigate this vulnerability, developers must ensure that all offset values derived from external firmware sources remain strictly within their defined unsigned integer domains throughout processing pipelines. The fix involves storing the table offset as an unsigned 32-bit value and implementing explicit unsigned comparisons before performing any pointer arithmetic operations. This approach ensures that boundary checks accurately reflect actual memory limits without being distorted by sign extension artifacts. Such corrections align with secure coding practices recommended for embedded systems interacting with untrusted firmware inputs, preventing similar integer overflow or underflow scenarios in future iterations of the remoteproc driver logic.
This vulnerability is categorized under CWE-190 Integer Overflow or Wraparound and relates to CWE-787 Out-of-bounds Read within the Common Weakness Enumeration framework. From a tactical perspective, it represents an exploitation technique consistent with ATT&CK subtechniques involving memory corruption for information gathering or privilege escalation attempts via malformed input processing in kernel drivers. Addressing these issues requires rigorous static analysis and dynamic fuzz testing of firmware parsing routines to detect similar type mismatches before they reach production environments.