CVE-2026-90416 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Fix stack out-of-bounds read in cc_params debugfs
get_param() reads a congestion parameter as a u32 but formats it with the signed "%d" into an 11-byte stack buffer. A value with bit 31 set, such as 0x80000000, renders as "-2147483648\n" whose full length is 12. snprintf() stores only 11 bytes yet returns 12, so simple_read_from_buffer() treats 12 bytes as valid and reads one byte past lbuf[].
Size the buffer for the widest unsigned decimal, format with "%u" to match the u32, and use scnprintf() so the length passed to simple_read_from_buffer() reflects the bytes actually stored.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in the Linux kernel involves a stack-based out-of-bounds read within the mlx5 RDMA driver's congestion control parameter debugfs interface. This flaw arises from an inconsistency between the data type being formatted and the buffer size allocated for its string representation, compounded by incorrect handling of return values from formatting functions. Specifically, the get_param function retrieves a congestion parameter as an unsigned 32-bit integer but formats it using the signed decimal format specifier "%d" into a stack-allocated character array of eleven bytes. This combination creates a critical edge case where large positive integers that have their most significant bit set are interpreted as negative numbers by the signed formatter.
When such a value, for example 0x80000000 which corresponds to -2147483648 in two's complement representation when treated as signed, is formatted, it produces a string that includes a leading minus sign and ten digits, totaling twelve characters including the null terminator. However, the destination buffer was sized for only eleven bytes, assuming an unsigned decimal format which would not require a negative sign for positive values within standard ranges or potentially misjudging the maximum width of an unsigned integer in this specific context. The snprintf function correctly limits its output to fit within the specified buffer size but returns the number of characters that would have been written if the buffer were large enough, resulting in a return value of twelve despite only eleven bytes being stored.
This discrepancy leads to a subsequent out-of-bounds read when simple_read_from_buffer is invoked with the length returned by snprintf. The function assumes that all returned bytes are valid and present within the provided output buffer. Consequently, it attempts to copy one byte beyond the end of the stack array lbuf into user space or internal buffers during the debugfs read operation. This constitutes a classic out-of-bounds read vulnerability, which can potentially lead to information disclosure by leaking adjacent stack memory contents to an unprivileged user with access to the relevant debugfs entry, or in more complex scenarios involving kernel exploitation techniques, it could contribute to further instability if the leaked data influences control flow logic elsewhere.
From a classification perspective, this issue aligns with CWE-125 Out-of-bounds Read and CWE-680 Integer Overflow to Buffer Overflow due to incorrect size calculation relative to formatted output length. In terms of attack vectors, it falls under ATT&CK technique T1074 Data Localized Staging if the leaked data is used for further exploitation within a compromised system context, though primarily it represents an information leakage vector accessible via local privilege escalation paths through debugfs interfaces which are often restricted but can be misconfigured or accessed by users with specific capabilities.
The remediation strategy implemented addresses these root causes through three precise modifications to the code logic. First, the buffer size is increased to accommodate the widest possible unsigned decimal representation of a 32-bit integer, ensuring sufficient space for any value from zero up to four billion two hundred ninety-four million nine hundred seventy-two thousand one hundred fifty-one without truncation risks related to length miscalculation. Second, the format specifier is changed from "%d" to "%u", aligning the formatting behavior with the unsigned nature of the u32 data type and preventing negative sign generation for high-bit values like 0x80000000. Third, scnprintf is utilized instead of snprintf; this variant returns only the number of bytes actually written into the buffer rather than the theoretical length required. This ensures that simple_read_from_buffer receives an accurate count of valid data, preventing it from accessing memory beyond the allocated stack frame boundaries and effectively eliminating the out-of-bounds read condition.