CVE-2026-89782 in Linux
Summary
by MITRE • 09/16/2026
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: reject restart table growth beyond U16_MAX entries
During $LogFile replay, log_replay() indexes the transaction table by the transact_id taken from the log record header. check_log_rec() only verifies that transact_id is non-zero and properly aligned, not its magnitude, so a crafted image can request an arbitrarily large index.
alloc_rsttbl_from_idx() grows the table to cover that index via extend_rsttbl(), which passes the new entry count to init_rsttbl():
rt = init_rsttbl(esize, used + add);
used + add is computed as u32 but init_rsttbl() takes a u16, and the count is stored in struct RESTART_TABLE as a __le16. When used + add exceeds U16_MAX it is truncated, init_rsttbl() allocates a table far smaller than the index requires, and alloc_rsttbl_from_idx() then dereferences and writes at the original, untruncated offset -- an out-of-bounds access past the allocation, reachable by mounting a crafted NTFS image.
BUG: KASAN: use-after-free in alloc_rsttbl_from_idx (fs/ntfs3/fslog.c:950) Read of size 4 at addr ffff8880327ffff8 by task exploit alloc_rsttbl_from_idx (fs/ntfs3/fslog.c:950) log_replay (fs/ntfs3/fslog.c:4562) ntfs_loadlog_and_replay (fs/ntfs3/fsntfs.c:324) ntfs_fill_super (fs/ntfs3/super.c:1393) get_tree_bdev_flags vfs_get_tree path_mount __x64_sys_mount
A restart table is limited to U16_MAX entries by its __le16 count, so a larger growth request is invalid input. Reject it in extend_rsttbl(); all callers already handle a NULL return.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/16/2026
The Linux kernel's NTFS3 filesystem driver contains a critical vulnerability within the log replay mechanism that allows for out-of-bounds memory access when processing maliciously crafted disk images. This flaw resides specifically in the fs/ntfs3/fslog.c module, where the function check_log_rec() validates transaction identifiers during $LogFile replay operations. While this validation ensures that the transact_id is non-zero and properly aligned, it fails to verify its magnitude against reasonable bounds. Consequently, an attacker who can supply a crafted NTFS image containing a log record with an excessively large transaction identifier can trigger arbitrary index growth within the restart table data structures. This lack of input sanitization creates a direct path for exploiting memory safety violations during the mounting and initialization phases of the filesystem.
The technical core of this vulnerability involves a type truncation error that leads to heap buffer overflows or use-after-free conditions. When log_replay() processes the crafted transaction ID, it calls alloc_rsttbl_from_idx(), which attempts to grow the restart table via extend_rsttbl(). The calculation for the new entry count is performed using u32 arithmetic, allowing values far exceeding 65535. However, this value is subsequently passed to init_rsttbl(), which expects a u16 argument corresponding to the __le16 field in struct RESTART_TABLE. When the computed size exceeds U16_MAX, it wraps around or truncates to a small positive integer due to implicit casting rules. As a result, init_rsttbl() allocates a memory buffer significantly smaller than what is required for the requested index offset. The subsequent code then proceeds to dereference and write data at the original, untruncated large offset, resulting in an out-of-bounds access past the allocated heap region.
The operational impact of this vulnerability is severe, as it can be triggered simply by mounting a maliciously constructed NTFS volume. The stack trace indicates that the exploit path flows through ntfs_fill_super and ntfs_loadlog_and_replay during standard filesystem attachment procedures using vfs_get_tree or get_tree_bdev_flags. Depending on memory layout and kernel configuration, this out-of-bounds write can lead to data corruption, denial of service via kernel panic triggered by KASAN reports such as use-after-free errors, or potentially arbitrary code execution if the attacker can control the contents written beyond the buffer boundary. The vulnerability is particularly dangerous because it requires no special privileges other than the ability to mount a filesystem device, which may be accessible in multi-user environments or through removable media vectors.
This issue aligns with CWE-190 Integer Overflow and CWE-787 Out-of-bounds Write vulnerabilities within the Common Weakness Enumeration framework. From an offensive security perspective, it maps to ATT&CK technique T1564.002 Hidden Files and Directories or more broadly to initial access vectors involving malicious media if physical or logical access to mount points is available. The root cause stems from insufficient validation of user-controlled input during the parsing of filesystem metadata structures, specifically failing to enforce domain-specific constraints on integer values before they influence memory allocation sizes.
To mitigate this vulnerability, developers must implement strict bounds checking within the extend_rsttbl() function or its callers prior to invoking init_rsttbl(). Specifically, any request for restart table growth that would result in a count exceeding U16_MAX should be rejected immediately with an appropriate error code. Since all existing callers of alloc_rsttbl_from_idx are designed to handle NULL returns indicating failure, enforcing this limit ensures the system remains stable and prevents the allocation of undersized buffers. System administrators relying on NTFS3 support should ensure their kernels are updated with patches addressing this specific logic flaw in fs/ntfs3/fslog.c. Until patched, restricting mount capabilities for untrusted or external storage devices can reduce the attack surface associated with this vulnerability.