CVE-2026-89838 in Linux
Summary
by MITRE • 09/16/2026
In the Linux kernel, the following vulnerability has been resolved:
f2fs: limit recovery filename logging to stored length
F2FS stores recovery filenames as a length plus a fixed-size i_name buffer. The buffer is not NUL-terminated, but recover_inode() and recover_dentry() print it with %s.
For a 255-byte filename, recovery logging can read past i_name into the following raw inode fields.
Print the name with a precision bounded by i_namelen and F2FS_NAME_LEN.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified in the Linux kernel's F2FS file system stems from an improper handling of string termination during recovery operations, specifically within the recover_inode and recover_dentry functions. F2FS is designed to store filenames using a length field followed by a fixed-size buffer known as i_name. This design choice optimizes storage efficiency but introduces complexity in memory management because the filename data stored in this buffer does not automatically include a null terminator character at its end. When these recovery routines attempt to log or print the recovered filenames, they utilize standard C string formatting functions that expect null-terminated strings. Consequently, if the actual length of the filename matches the maximum capacity of the i_name buffer without leaving space for a null byte, the printing operation will continue reading memory beyond the intended boundary until it encounters a zero value in adjacent memory regions.
This flaw results in an out-of-bounds read vulnerability that can lead to information disclosure and potential system instability. By using the %s format specifier without restricting the output length based on the actual stored filename size, the kernel reads past the i_name buffer into subsequent fields of the raw inode structure. This behavior allows sensitive internal data structures or potentially other file metadata to be exposed in log outputs. In a local context, this could allow an attacker with access to system logs to view private information contained within adjacent memory slots. Furthermore, if such logging mechanisms are accessible through interfaces that can trigger recovery processes repeatedly, it may contribute to denial of service conditions by filling up disk space or causing kernel panics due to accessing invalid memory regions during the read operation.
From a technical classification perspective, this issue aligns with CWE-126, which denotes Buffer Over-read vulnerabilities where software reads data past the end of a buffer. It also relates to CWE-787, as it involves improper access control leading to unauthorized information exposure through out-of-bounds memory access. In terms of attack vectors and tactics, this vulnerability can be leveraged in scenarios involving local privilege escalation or reconnaissance if an attacker can influence file creation parameters to trigger the specific condition where filenames are maximally long without null termination. The ATT&CK framework categorizes such behaviors under techniques related to Collection via File and Directory Discovery or potentially Command and Control if log data is exfiltrated, though primarily it serves as a mechanism for information gathering within the system environment.
The resolution implemented in this patch addresses the root cause by enforcing strict bounds on string printing operations during recovery. Instead of relying on implicit null termination which may not exist, the code now explicitly limits the number of characters printed to match the stored filename length defined by i_namelen and capped at F2FS_NAME_LEN. This ensures that only valid data within the allocated buffer is processed for logging purposes. To mitigate similar risks in other parts of the kernel or third-party software utilizing fixed-size buffers, developers should always validate string lengths before passing them to functions expecting null-terminated strings. Utilizing length-limited formatting specifiers such as %.*s instead of %s provides a robust defense against buffer over-read vulnerabilities. Regular code audits focusing on memory boundary checks and strict adherence to standard library function contracts are essential practices for maintaining kernel integrity and preventing information leakage through logging mechanisms.