Cloudanix VulnDB

CVE-2026-53029

None

CVSS

—

EPSS

0.1%

Published

Jun 24, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A flaw in Linux handling of NTFS drives could let a specially prepared drive or disk image make a system behave unpredictably or crash when it is accessed.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Data Exposure
Component
OS kernel
Class
Information Disclosure
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

CVE-2026-53029 is a Linux kernel ntfs3 filesystem bug where a zero-length run can cause ntfs_iomap_begin() to use an uninitialized logical cluster number (LCN). The immediate technical consequence is undefined kernel behavior when processing NTFS file mappings, potentially including kernel memory disclosure to diagnostic tooling, incorrect block mapping, kernel warnings, or a denial-of-service condition depending on build configuration, memory sanitizer coverage, and execution path. The issue is local and requires interaction with NTFS filesystem handling, such as mounting or accessing a crafted or malformed NTFS volume or image.

Why it matters to the business

Organizations that allow Linux systems to mount untrusted NTFS media or disk images could face workstation, server, forensic, or file-processing instability. The most likely operational impact is local system crash or unreliable filesystem behavior during NTFS access; information exposure risk is plausible but constrained to local filesystem operations. The low EPSS score, lack of known exploitation, and absence from CISA KEV suggest low immediate internet-scale exploitation urgency, but kernel fixes should still be prioritized for systems that process removable media, user-supplied disk images, or NTFS-formatted storage.

How an attack unfolds

An attacker would need a path to make a vulnerable Linux kernel parse NTFS metadata that triggers the zero-length run condition in the ntfs3 driver. In a realistic scenario, the attacker supplies a crafted NTFS USB drive, virtual disk, forensic image, archive containing a disk image, or other NTFS-formatted storage object. When a vulnerable system mounts or scans the volume and accesses affected file mappings, ntfs_iomap_begin() can reach a code path where lcn is used before initialization. Depending on kernel configuration and runtime conditions, this may expose stale kernel memory values through subsequent behavior or cause a kernel fault, warning, or crash. There are no named threat actors, ransomware use, KEV listing, or public exploit maturity reported for this issue in the provided data.

How to fix it

Update the Linux kernel to a version that includes the ntfs3 fix moving the zero-length clen check before lcn update/use in ntfs_iomap_begin(). Because no distribution-specific affected products or fixed package versions were provided, use vendor advisories for the deployed Linux distribution to identify the patched kernel package. Reboot systems after kernel update to ensure the fixed kernel is running. Where immediate patching is not possible, reduce exposure by preventing automatic mounting of untrusted NTFS volumes, disabling or restricting removable media, avoiding processing untrusted disk images on production systems, using isolated sandboxes for filesystem analysis, and considering use of alternative NTFS handling workflows until patched.

How to confirm the fix worked

Confirm the running kernel includes the upstream ntfs3 fix for the uninitialized lcn condition in ntfs_iomap_begin(). Validate by checking the installed and booted kernel version against the Linux distribution security advisory, not just the package repository version. On Linux hosts, compare `uname -r` with the fixed kernel package version from the vendor and confirm the system has been rebooted after update. Review whether the ntfs3 module is present or loaded using tools such as `lsmod` and whether NTFS volumes are mounted using ntfs3. For mitigation validation, confirm automount policies for removable media are disabled or restricted and that workflows handling untrusted NTFS images run in isolated environments.

Typical attack path

  1. Prepare a malformed or crafted NTFS filesystem image or physical NTFS-formatted medium containing metadata that triggers a zero-length run path.
  2. Deliver the NTFS content to a target user, automated scanner, forensic workstation, file ingestion pipeline, virtualization workflow, or system that mounts untrusted storage.
  3. Cause the vulnerable Linux kernel ntfs3 driver to mount or access the crafted filesystem.
  4. Trigger file mapping activity that reaches ntfs_iomap_begin() and uses an uninitialized lcn value.
  5. Leverage the resulting behavior for local information exposure, kernel instability, or denial of service where feasible.

How to detect it

Look for evidence that vulnerable systems mounted or accessed untrusted NTFS content shortly before kernel warnings, crashes, or filesystem errors. Relevant log sources include kernel logs, `dmesg`, journald, `/var/log/kern.log`, `/var/log/messages`, audit logs for mount activity, removable media/udev logs, endpoint telemetry, and virtualization or forensic-tool logs that record disk image attachment. Search for ntfs3-related errors, KMSAN uninitialized-value reports in ntfs_iomap_begin(), stack traces involving fs/ntfs3/inode.c, iomap_iter, kernel oops/panic events, and mount events for NTFS volumes from USB devices, loop devices, or virtual disks. Because the provided information does not include a known exploit payload, network signature, attacker tool, or persistent artifact, detection should focus on suspicious NTFS mount/access events correlated with kernel instability or sanitizer warnings.

  • BUG: KMSAN: uninit-value in ntfs_iomap_begin
  • ntfs_iomap_begin+0x8c0/0x1460 fs/ntfs3/inode.c:825
  • ntfs_iomap_begin+0x15d/0x1460 fs/ntfs3/inode.c:786
  • iomap_iter+0x9b7/0x1540 fs/iomap/iter.c:110
  • fs/ntfs3/inode.c:825
  • fs/ntfs3/inode.c:786
  • ntfs3
  • type ntfs3
  • mount -t ntfs3
  • kernel: BUG: KMSAN: uninit-value
  • kernel: Oops
  • kernel panic

What your security team should do

  • Patch Linux kernels through vendor-supported updates, prioritizing endpoints, forensic workstations, file-ingestion systems, virtualization hosts, and any systems that mount user-supplied NTFS media or images.
  • Inventory systems where the kernel ntfs3 driver is available or in use, especially systems with removable media, automount, backup, e-discovery, malware analysis, or digital forensics workflows.
  • Temporarily block or restrict automatic mounting of NTFS removable media and untrusted NTFS disk images until patched.
  • Use sandboxed or disposable analysis environments for untrusted disk images and removable media processing.
  • Monitor kernel logs for ntfs3, iomap, KMSAN, uninitialized-value, kernel oops, or panic events associated with NTFS mount or access activity.
  • Treat this as lower internet-facing urgency due to low EPSS, no KEV status, and no known exploit maturity, but include it in normal kernel patch cycles because exploitation may be local and media-driven.

The record

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: prevent uninitialized lcn caused by zero len syzbot reported a uninit-value in ntfs_iomap_begin [1]. Since runs was not touched yet, run_lookup_entry() immediately fails and returns false, which makes the value of "*len" 0. Simultaneously, the new value and err value are also 0, causing the logic in attr_data_get_block_locked() to jump directly to ok, ultimately resulting in *lcn being triggered before it is set [1]. In ntfs_iomap_begin(), the check for a 0 value in clen is moved forward to before updating lcn to avoid this [1]. [1] BUG: KMSAN: uninit-value in ntfs_iomap_begin+0x8c0/0x1460 fs/ntfs3/inode.c:825 ntfs_iomap_begin+0x8c0/0x1460 fs/ntfs3/inode.c:825 iomap_iter+0x9b7/0x1540 fs/iomap/iter.c:110 Local variable lcn created at: ntfs_iomap_begin+0x15d/0x1460 fs/ntfs3/inode.c:786

Affected packages

Ecosystem Package Introduced Fixed