CVE-2026-53027

What it actually does

This is a Linux kernel ntfs3 filesystem flaw that can trigger a kernel warning while handling compressed or sparse NTFS file attributes. When virtual cluster numbers are frame-aligned, the code may load the run list for one NTFS attribute segment but fail to load the separate segment containing the original cluster. A subsequent lookup treats the cluster as sparse and reaches a WARN_ON(1). On systems configured to panic on kernel warnings, or where repeated kernel warnings disrupt service, this can become a local denial-of-service condition. The issue is not described as remote code execution or privilege escalation.

Why it matters to the business

Systems that mount NTFS volumes using the in-kernel ntfs3 driver can be crashed or destabilized by a crafted or unusual NTFS filesystem, especially if removable media, disk images, backup media, or user-supplied storage are automatically mounted. The risk is operational disruption rather than data theft. EPSS is very low, it is not in CISA KEV, and no public exploit maturity is reported, so urgency is generally lower than internet-facing remote flaws, but higher for endpoints, kiosks, forensic workstations, virtualization hosts, or file-processing systems that handle untrusted NTFS media.

How an attack unfolds

An attacker prepares an NTFS filesystem containing a compressed or sparse attribute arranged so that frame alignment causes the current virtual cluster and the original virtual cluster to fall in different NTFS attribute segments. The attacker then gets a vulnerable Linux system to mount that filesystem with the ntfs3 driver and perform file operations that cause attr_data_get_block_locked() to allocate or look up clusters for the crafted attribute. Because the kernel has not loaded the run list for the original cluster's segment, run_lookup_entry() returns a sparse-cluster result and the kernel hits a WARN_ON(1). If the host is configured with panic_on_warn, this warning can immediately panic the kernel; otherwise it may still cause service instability, alert noise, or repeated failures while accessing the crafted volume.

How to fix it

Apply a vendor kernel update that includes the ntfs3 fix for the missing run load check in attr_data_get_block_locked(). Because no product-specific fixed versions were provided, use the fixed kernel packages from the relevant Linux distribution, appliance vendor, hypervisor vendor, or embedded platform supplier and verify that their changelog references this issue or the corresponding upstream ntfs3 patch. Where patching is delayed, reduce exposure by disabling or blacklisting the ntfs3 kernel module where NTFS support is not required, disabling automatic mounting of removable media, avoiding mounting untrusted NTFS images on production systems, mounting untrusted filesystems only inside disposable sandboxes or VMs, and considering a userspace NTFS implementation where appropriate. On systems where availability is more important than immediate panic-on-warning behavior, review whether kernel.panic_on_warn is intentionally enabled, but do not use that as a substitute for patching.

How to confirm the fix worked

Confirm remediation by verifying the running kernel version and vendor package changelog include the ntfs3 fix for this issue. Check whether ntfs3 is present or loaded with commands such as lsmod, modinfo ntfs3, and inspection of /sys/module/ntfs3. Confirm automount policies do not automatically mount untrusted NTFS media where that is not required. After patching, monitor dmesg or journalctl -k while performing normal NTFS mount and file-access operations and confirm there are no kernel warnings or stack traces involving ntfs3, attr_data_get_block_locked(), or run_lookup_entry(). Avoid validating with untrusted proof-of-concept media on production hosts; use an isolated test system if functional reproduction is needed.

Typical attack path

1. Create or obtain a specially structured NTFS filesystem containing compressed or sparse attributes whose cluster mappings cross attribute segment boundaries after frame alignment.
2. Deliver the filesystem to the target as removable media, a disk image, a virtual disk, backup media, or another storage object likely to be mounted on Linux.
3. Cause the vulnerable system to mount the NTFS volume using the in-kernel ntfs3 driver rather than a userspace NTFS implementation.
4. Trigger reads, writes, allocation, or metadata operations against the crafted compressed or sparse file attribute.
5. The kernel enters the vulnerable ntfs3 path, fails to load the run list for the original cluster segment, and reaches the WARN_ON(1).
6. If panic_on_warn or similar hardening is enabled, the system panics; otherwise the system records kernel warnings and may experience degraded filesystem availability or repeated faults.

How to detect it

Look for signs of prior kernel warnings or crashes involving the ntfs3 filesystem driver. Primary log sources are dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore records, systemd-coredump metadata, audit logs for mount activity, udev logs for removable media insertion, and endpoint telemetry showing attached USB storage or mounted disk images. Search for kernel stack traces containing attr_data_get_block_locked(), run_lookup_entry(), fs/ntfs3, or ntfs3 near the time of NTFS mount events. Correlate any such warnings with mount commands using filesystem type ntfs3, automatic desktop/media mounts, loopback-mounted disk images, virtual disk attachments, or backup/forensic tooling. There are no known network indicators for this vulnerability; evidence is host-local and kernel-log based. If crash dumps are available, inspect the stack for ntfs3 code paths and confirm whether kernel.panic_on_warn caused a warning to escalate into a panic.

• attr_data_get_block_locked
• run_lookup_entry
• fs/ntfs3
• ntfs3
• SPARSE_LCN
• WARNING: CPU:
• kernel: ntfs3:
• /sys/module/ntfs3
• /proc/sys/kernel/panic_on_warn
• type=ntfs3

What your security team should do

• Inventory Linux systems that mount NTFS volumes, especially endpoints, forensic workstations, file ingestion systems, virtualization hosts, backup systems, and systems with removable-media automounting enabled.
• Prioritize kernel updates on systems that handle untrusted NTFS media or disk images, even though public exploitation likelihood is currently low.
• Disable ntfs3 or restrict NTFS mounting on servers and production systems that do not require it.
• Disable automatic mounting of removable media and require sandboxed analysis for user-supplied NTFS volumes or disk images.
• Review kernel.panic_on_warn settings on availability-sensitive systems so teams understand whether a kernel warning can become a full system crash.
• Add monitoring for kernel warnings and crashes involving ntfs3 functions, and correlate them with recent NTFS mounts, USB insertions, disk-image processing, or virtual disk attachment events.
• Document an operational procedure for handling untrusted filesystems in disposable environments rather than on production hosts.