CVE-2026-31716
High · 7.8CVSS
7.8
EPSS
0.1%
Published
May 1, 2026
CISA due date
—
Cloudanix analysis
A malicious or corrupted Windows-formatted drive or disk image could crash a Linux system or possibly let an attacker gain control if the system mounts it.
- Exploitation
- Requires User Interaction
- Attacker needs
- User Interaction
- Complexity
- Moderate
- Impact
- Full Compromise
- Component
- OS kernel
- Class
- Memory Corruption
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
This is a Linux kernel memory-corruption flaw in the ntfs3 filesystem driver during NTFS journal replay. The vulnerable code validates a file record's total size but fails to validate the on-disk rec->used field before using it in length calculations for memmove operations. A malformed NTFS filesystem can set rec->used smaller than an attribute offset or larger than the record size, causing integer underflow or oversized copy lengths into a small kernel buffer. Depending on kernel build, memory layout, and runtime protections, this can lead to kernel out-of-bounds read/write, kernel crash, information disclosure, or potentially local privilege escalation through kernel memory corruption.
Why it matters to the business
Systems that automatically or manually mount untrusted NTFS media, disk images, virtual disks, forensic images, or removable storage are most exposed. Successful exploitation could crash affected Linux systems or, in a worst case, allow an attacker with access to get malicious storage mounted to gain elevated privileges. The EPSS score is very low, there is no known public exploit maturity, and it is not listed in CISA KEV, so broad active exploitation is unlikely at this time; however, the impact is high for workstations, file-processing systems, virtualization hosts, recovery tools, and environments that handle external or customer-supplied storage images.
How an attack unfolds
An attacker prepares a malformed NTFS filesystem containing crafted journal/file-record metadata where the rec->used value is inconsistent with the actual record size and validated attribute offsets. The attacker then needs the target Linux system to mount or process that filesystem using the kernel ntfs3 driver, such as through a USB drive, attached disk, downloaded disk image, virtual machine image, forensic image, or automated media-processing workflow. During mount or recovery, ntfs3 replays journal actions and reaches handlers such as DeleteAttribute, CreateAttribute, or change_attr_size. The malformed rec->used value causes unsafe length calculations for memmove, resulting in an oversized memory copy in kernel context. The likely observable outcomes are a kernel oops, panic, or denial of service; with additional exploit engineering, the same memory corruption primitive may be usable for privilege escalation or kernel memory disclosure.
How to fix it
Apply the Linux kernel update from the relevant distribution or vendor that includes the ntfs3 fix bounding rec->used during journal replay file-record validation. No exact fixed kernel version was provided in the input, so remediation should follow vendor advisories for the affected Linux kernel packages. Where immediate patching is not possible, reduce exposure by disabling or avoiding the in-kernel ntfs3 driver for untrusted media, preventing automatic mounting of removable storage, restricting mount privileges to trusted administrators, processing untrusted NTFS images only in isolated sandboxes or disposable virtual machines, and using read-only or offline analysis workflows where practical. Systems that do not mount NTFS filesystems with ntfs3 have substantially reduced practical exposure.
How to confirm the fix worked
Confirm that affected hosts are running a vendor kernel build containing the ntfs3 rec->used bounds-check fix. Validate package state with the distribution package manager and compare the running kernel to the vendor's fixed advisory. If source validation is required, verify that fs/ntfs3 journal-replay/file-record validation rejects rec->used values smaller than required offsets or larger than the record size before memmove length calculations. Operationally, confirm that untrusted NTFS media is not auto-mounted, that only authorized users can mount filesystems, and that removable-media policies are enforced. For exposure testing, safely verify in a non-production lab that malformed NTFS samples no longer cause kernel oops, KASAN reports, or ntfs3 crashes during mount/journal replay.
Typical attack path
- Craft a malicious NTFS filesystem or disk image with corrupted journal/file-record metadata.
- Deliver the filesystem to a target path where it may be mounted or inspected, such as removable media, a virtual disk, a forensic image, or an archive containing a disk image.
- Trigger the affected Linux system to mount or parse the filesystem using the ntfs3 kernel driver.
- Wait for NTFS journal replay to process the malformed file record.
- Abuse the invalid rec->used value to cause an underflow or oversized memmove in kernel memory.
- Cause a kernel crash, or attempt to shape the memory corruption for information disclosure or local privilege escalation.
How to detect it
Retrospective detection should focus on evidence that affected systems mounted suspicious NTFS volumes shortly before kernel faults. Review kernel logs, journald, syslog, dmesg archives, crash dumps, KASAN/KMSAN reports, and endpoint telemetry for ntfs3-related oops, panic, slab-out-of-bounds, general protection fault, or memmove traces. Correlate those events with removable-media insertion, loop-device creation, VM disk attachment, mount commands, file-ingestion jobs, or forensic-image processing. On systems with auditd or EDR telemetry, look for mount or losetup activity involving NTFS images followed by kernel instability or reboot. Preserve suspicious NTFS images, crash dumps, vmcores, and kernel logs for analysis. There are no known threat actors or public exploit campaigns in the provided data, and no network indicators are expected because exploitation is local and filesystem-triggered.
- ntfs3
- fs/ntfs3
- check_file_record
- do_action
- DeleteAttribute
- CreateAttribute
- change_attr_size
- BUG: KASAN: slab-out-of-bounds
- BUG: KASAN: out-of-bounds
- kernel BUG at fs/ntfs3
- general protection fault
- Oops:
- Kernel panic
- memmove
- journal replay
- Buffer overflow detected
- losetup
- mount -t ntfs3
What your security team should do
- Prioritize kernel patching on workstations, forensic analysis systems, virtualization hosts, file-ingestion systems, and servers that handle removable media or untrusted disk images.
- Disable automatic mounting of removable media and untrusted NTFS volumes until patched.
- Restrict mount permissions and audit users or services that can mount loopback devices, USB storage, virtual disks, or customer-supplied images.
- Process untrusted NTFS filesystems only inside isolated virtual machines or sandboxes with disposable kernels.
- Monitor kernel logs for ntfs3 crashes, KASAN reports, general protection faults, and oops traces involving journal replay functions.
- Because EPSS is low and there is no known KEV or ransomware association, treat this as a high-impact local/media-handling risk rather than an internet-scale emergency.
- Include malformed filesystem handling in vulnerability management for endpoint, lab, recovery, and digital forensics tooling, not only server patch programs.
The record
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate rec->used in journal-replay file record check check_file_record() validates rec->total against the record size but never validates rec->used. The do_action() journal-replay handlers read rec->used from disk and use it to compute memmove lengths: DeleteAttribute: memmove(attr, ..., used - asize - roff) CreateAttribute: memmove(..., attr, used - roff) change_attr_size: memmove(..., used - PtrOffset(rec, next)) When rec->used is smaller than the offset of a validated attribute, or larger than the record size, these subtractions can underflow allowing us to copy huge amounts of memory in to a 4kb buffer, generally considered a bad idea overall. This requires a corrupted filesystem, which isn't a threat model the kernel really needs to worry about, but checking for such an obvious out-of-bounds value is good to keep things robust, especially on journal replay Fix this up by bounding rec->used correctly. This is much like commit b2bc7c44ed17 ("fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot") which checked different values in this same switch statement.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|---|---|---|
| openSUSE:Tumbleweed | kernel-source | 0 | 7.0.7-1.1 |
Related vulnerabilities
- CVE-2026-53354 In the Linux kernel, the following vulnerability has been resolved: arm64: errata… Also affects kernel-source
- CVE-2026-53325 In the Linux kernel, the following vulnerability has been resolved: agp/amd64: Fix broken… Also affects kernel-source
- CVE-2026-52946 In the Linux kernel, the following vulnerability has been resolved: fs/fcntl: fix… Also affects kernel-source
- CVE-2026-52907 In the Linux kernel, the following vulnerability has been resolved: media: rockchip… Also affects kernel-source
- CVE-2026-52906 In the Linux kernel, the following vulnerability has been resolved: 9p: fix access mode… Also affects kernel-source
- CVE-2026-52905 In the Linux kernel, the following vulnerability has been resolved: mm/damon/core… Also affects kernel-source
- CVE-2026-52904 In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix… Also affects kernel-source
- CVE-2026-46332 In the Linux kernel, the following vulnerability has been resolved: greybus… Also affects kernel-source