Description

In the Linux kernel, the following vulnerability has been resolved: ntfs: fix u16 truncation of restart-area length check ntfs_check_restart_area() validates that the $LogFile restart area and its trailing log client record array fit within the system page size: u16 ra_ofs, ra_len, ca_ofs; ... ra_len = ca_ofs + le16_to_cpu(ra->log_clients) * sizeof(struct log_client_record); if (ra_ofs + ra_len > le32_to_cpu(rp->system_page_size) || ...) return false; ra_len is u16, but the right-hand side is computed in size_t (sizeof(struct log_client_record) == 160). Both ca_ofs and log_clients come straight from the on-disk restart area. With an on-disk log_clients of 410 the product 410 * 160 = 65600; adding ca_ofs and storing into the u16 ra_len truncates modulo 65536 (e.g. ca_ofs 64 gives ra_len 128), so the "fits in the page" check passes even though the client array described by log_clients extends far beyond the page. ntfs_check_log_client_array() then walks the array bounded only by the on-disk log_clients count: cr = ca + idx; if (cr->prev_client != LOGFILE_NO_CLIENT) ... For log_clients 410 it dereferences records up to ca + 409 * 160, ~64 KiB past the kvzalloc(system_page_size) restart-page buffer -- an out-of-bounds read of attacker-controlled extent, reachable when a crafted NTFS image is mounted (load_and_check_logfile() at mount time). This is the in-kernel analogue of CVE-2022-30789, fixed in the ntfs-3g userspace driver but never in this revived classic driver. Compute the restart-area length in a u32 so the existing bounds check rejects an over-large client array instead of being defeated by the truncation. Widen ra_ofs and ca_ofs to u32 as well: both are loaded from __le16 on-disk fields and every comparison already promotes to int/size_t, so this changes no result and keeps the declaration uniform.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-08-28T08:16:52.510Z",
  "pubdate": "2026-08-28T08:16:52.510Z",
  "executiveSummary": "A critical integer truncation vulnerability exists in the classic Linux kernel NTFS driver's processing of $LogFile restart areas.\nThe vulnerability occurs due to the improper handling of the restart-area length calculation, where a 16-bit unsigned integer (u16) is used to store a value that can exceed 65,535 bytes.\nBy crafting a malicious NTFS image with an inflated 'log_clients' count, an attacker can trigger an integer wrap-around. This allows the restart-area length validation logic to pass incorrectly, despite the actual structure size extending well beyond the allocated system page buffer.\nThis flaw facilitates an out-of-bounds read, potentially leading to kernel memory disclosure or system instability.\nThe vulnerability is reachable during the mount process (load_and_check_logfile), meaning it can be triggered locally by mounting a maliciously crafted filesystem. Similar in nature to CVE-2022-30789, this flaw impacts the kernel driver's ability to safely validate on-disk metadata.\nThe risk is categorized as high, as it allows attackers to bypass security boundaries during filesystem initialization, potentially leading to a kernel panic or unauthorized access to sensitive kernel memory.",
  "technicalDetails": "The root cause of the vulnerability lies in the 'ntfs_check_restart_area' function, which validates the size of the $LogFile restart area. The function incorrectly uses a u16 data type to store 'ra_len', which represents the combined offset and length of the log client record array.\nBecause the 'log_client_record' structure size is 160 bytes, a sufficiently large 'log_clients' value (e.g., 410) results in a product (65,600) that exceeds the maximum capacity of a 16-bit integer (65,535).\nWhen this product is stored in the u16 variable, the value undergoes modulo 65,536 truncation. This causes the 'ra_len' variable to wrap around to a small, valid-looking number. Consequently, the conditional check 'if (ra_ofs + ra_len > le32_to_cpu(rp->system_page_size))' evaluates to false, failing to identify that the actual array length significantly exceeds the allocated system page size buffer.\nFollowing this validation bypass, the 'ntfs_check_log_client_array' function proceeds to process the client records. It uses the attacker-controlled 'log_clients' count to iterate through the array, performing memory dereferences at addresses calculated as 'ca + idx'.\nBecause the validation check was bypassed, these dereferences occur outside the bounds of the 'kvzalloc(system_page_size)' restart-page buffer. Specifically, for a 'log_clients' value of 410, the code attempts to read approximately 64 KiB of data beyond the buffer allocated for the restart page.\nThis out-of-bounds read exposes the kernel to arbitrary memory access based on the contents of the crafted NTFS image. An attacker can place malicious structures or specific data patterns in the image that, when accessed by the kernel, lead to an information leak or a system crash (kernel panic).\nThe vulnerability is triggered during the NTFS mount operation via 'load_and_check_logfile'. Since the validation happens before the filesystem is fully mounted, no special user privileges beyond the ability to mount a filesystem are required. This creates a significant vector for local exploitation or exploitation via removable media containing malicious NTFS structures."
}