CVE-2026-80672
Out-of-Bounds Read in Linux Kernel's Legacy NTFS Driver via Crafted $LogFile
The legacy (classic) in-kernel NTFS driver in the Linux kernel computes the $LogFile restart-area length into a 16-bit variable, so an on-disk log_clients count of 410 (410 x 160 = 65,600 bytes) wraps modulo 65,536 and defeats the 'fits within system page size' bounds check in ntfs_check_restart_area(). Mounting a crafted NTFS image then causes ntfs_check_log_client_array() to walk records up to ~64 KiB past the end of the kvzalloc'd restart-page buffer, producing an out-of-bounds read of attacker-controlled extent during load_and_check_logfile() at mount time. A local attacker who can supply such an image gains access to kernel heap memory beyond the buffer; the assigned CVSS 3.1 score is 8.8 (high) with changed scope. Affected are Linux systems that mount untrusted NTFS filesystems using the legacy in-kernel driver (fs/ntfs), such as via USB drives or dual-boot partitions; this is the in-kernel analogue of CVE-2022-30789, which was fixed in the ntfs-3g userspace driver but never in this revived classic driver. No public exploit or proof-of-concept is known, the issue is not in CISA KEV, and EPSS estimates only a 0.1% probability of exploitation within 30 days.
What to do: Apply the upstream kernel commit that computes the restart-area length in u32 (also widening ra_ofs/ca_ofs) once it reaches your vendor's kernel, and follow your distribution's security advisory for a fixed kernel package. Until patched, avoid mounting untrusted NTFS images or removable media with the legacy in-kernel driver and use the maintained ntfs3 or FUSE ntfs-3g drivers for NTFS mounts instead. Check exposure by verifying whether CONFIG_NTFS_FS (the legacy driver) is enabled in running kernels and whether untrusted users can mount NTFS volumes.
| Linux kernel - legacy in-kernel NTFS driver (fs/ntfs) | — |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
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.
- Vector
- CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
In the news0 stories
No ingested article mentions this CVE yet.