CVE-2026-80672 in Linux
Summary
by MITRE • 08/28/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/28/2026
The Linux kernel's NTFS filesystem driver contains a critical integer truncation vulnerability within the ntfs_check_restart_area function that allows for out-of-bounds memory reads when mounting crafted disk images. This flaw arises from an incorrect data type selection during the validation of the $LogFile restart area and its associated log client record array. The code calculates the total length required to accommodate these structures by combining a file offset with the product of the number of log clients and the size of each client record structure, which is one hundred sixty bytes. While this calculation involves values derived directly from on-disk metadata that can be controlled by an attacker, the result is stored in a sixteen-bit unsigned integer variable named ra_len. This type mismatch creates a scenario where large calculated lengths exceed the maximum value representable by a u16, resulting in silent truncation modulo sixty-five thousand five hundred thirty-six. Consequently, a legitimately oversized request that should trigger a rejection check instead wraps around to fit within the bounds of a standard system page size, effectively bypassing security validations designed to prevent buffer overflows and out-of-bounds access.
The operational impact of this vulnerability is severe because it enables an attacker with physical or virtualized access to storage media containing maliciously crafted NTFS filesystems to trigger kernel memory corruption upon mounting the volume. When the truncated length check passes, subsequent code paths proceed to walk through the log client array using the original on-disk count rather than the truncated value. For example, if a disk image specifies four hundred ten clients, the driver attempts to access records up to index four hundred nine. Given that each record is one hundred sixty bytes wide, this results in memory accesses extending approximately sixty-four kilobytes beyond the allocated buffer for the restart page. This constitutes an out-of-bounds read of attacker-controlled extent data reachable during the mount process via load_and_check_logfile functions. The vulnerability serves as a direct analogue to CVE-2022-30789, which affected the ntfs-3g userspace driver but was never remediated in this classic kernel-side implementation, leaving systems relying on native NTFS support exposed to potential information disclosure or further exploitation vectors depending on what data resides adjacent to the allocated buffer.
From a technical classification perspective, this issue aligns with CWE-190 Integer Overflow or Wraparound and CWE-787 Out-of-bounds Read within the Common Weakness Enumeration framework. The root cause is fundamentally an integer overflow that leads to insufficient bounds checking, allowing access to memory regions outside the intended allocation boundaries. In terms of attack tactics, this vulnerability facilitates initial code execution or reconnaissance through malicious media insertion, mapping closely to ATT&CK technique T1566.002 Spearphishing Attachment involving specially crafted files designed to exploit software vulnerabilities upon opening or mounting. The lack of proper type promotion during arithmetic operations on untrusted input data represents a classic implementation error that undermines the integrity checks intended by kernel developers.
To mitigate this vulnerability, the Linux kernel maintainers have implemented fixes that widen the computational context for restart area length calculations from sixteen-bit to thirty-two-bit unsigned integers. By computing ra_len as a u32 and similarly widening related offset variables like ra_ofs and ca_ofs to match the broader type system used in comparisons, the code ensures that large values derived from on-disk structures are not truncated before validation. This change allows the existing bounds checks against le32_to_cpu(rp->system_page_size) to correctly identify and reject oversized client arrays rather than being deceived by wrapped-around small values. System administrators should apply kernel updates containing this patch immediately, particularly for systems that mount NTFS volumes from untrusted or removable media sources. Additionally, organizations relying on NTFS support in Linux environments should verify their kernel versions against known vulnerability databases to ensure they are not running affected releases susceptible to exploitation via crafted disk images.