CVE-2026-93061 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
gpu: host1x: Avoid stack over-read in debug output helpers
host1x_debug_output() and host1x_debug_cont() used vsnprintf(), which returns the length the formatted string would have reached with an unbounded buffer. That return value was passed straight to o->fn as the number of bytes to emit.
This could cause a read past end of the output buffer if a call to host1x_debug_* produced a string longer than 256 bytes. This only affected the debugfs files as the printk debug sink ignores the number of bytes. In practice, this is very unlikely to occur.
Fix by switching to vscnprintf(), which returns the number of bytes actually written.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The identified vulnerability resides within the Linux kernel's host1x GPU driver subsystem, specifically affecting the debug output helper functions named host1x_debug_output and host1x_debug_cont. These functions are responsible for formatting diagnostic strings that are typically exposed through the debugfs interface to assist developers in troubleshooting hardware interactions. The core technical flaw stems from an incorrect handling of buffer length calculations when utilizing standard C library string formatting routines. Specifically, these helper functions invoke vsnprintf to format a message into a fixed-size stack buffer. While vsnprintf is generally safe against write overflows because it respects the provided size limit, its return value indicates the total number of characters that would have been written if the buffer had been large enough, not necessarily what was actually stored in the limited buffer space.
The operational impact arises from a logical error where this returned length value is passed directly to an output function as the count of bytes to emit or process. If the formatted string exceeds the capacity of the stack buffer, which is defined as 256 bytes in this context, the return value will reflect that larger hypothetical size rather than the actual number of characters safely contained within the buffer boundaries. Consequently, subsequent operations relying on this length metric may attempt to read data from memory locations beyond the end of the allocated stack array. This constitutes a classic out-of-bounds read vulnerability, often categorized under CWE-126 Buffer Over-read. Although the immediate risk is limited because the affected code path is primarily accessible through debugfs files which require specific privileges or conditions to trigger, an attacker with local access could potentially exploit this discrepancy to leak kernel stack memory contents into user space.
This type of vulnerability aligns with common patterns found in systems programming where return value semantics are misunderstood. The ATT&CK framework classifies such information disclosure techniques under Tactic TA0010 Exfiltration and Technique T1056 Input Capture or potentially T1074 Data Staged if the leaked data is used for further exploitation, though here it represents a direct memory leak via debug interfaces. The severity is generally considered low to medium due to the restricted attack surface involving debugfs, but it remains significant because kernel stack leaks can reveal sensitive information such as return addresses or other pointers that aid in bypassing security mitigations like KASLR.
The resolution involves replacing the call to vsnprintf with vscnprintf within these helper functions. Unlike its counterpart, vscnprintf returns the number of bytes actually written into the buffer, ensuring that any subsequent processing uses a length value that is strictly bounded by the physical limits of the allocated memory space. This change guarantees that no read operations will extend beyond the end of the 256-byte stack array. To mitigate similar risks in other parts of the kernel or third-party drivers, developers should consistently verify whether formatting functions return theoretical lengths or actual written counts and ensure that buffer boundaries are respected during all subsequent data handling steps. Regular static analysis and code reviews focusing on string manipulation routines can help prevent such logical errors from being introduced into critical system components.