Description

In the Linux kernel, the following vulnerability has been resolved: ntfs: protect runlist updates with the runlist lock ntfs_non_resident_attr_shrink() calls runlist helpers that require the runlist write lock, but did not hold it while freeing clusters and truncating the runlist. Serialize those operations and the resident conversion with the runlist lock. ntfs_attr_map_cluster() can merge a newly allocated run before updating mapping pairs. If the update fails, free the clusters and restore both the in-memory runlist and on-disk mapping pairs from a saved runlist. Mark the volume in error if either rollback step fails.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-10-06T09:18:23.200Z",
  "pubdate": "2026-10-06T09:18:23.200Z",
  "executiveSummary": "The vulnerability is a race condition within the Linux kernel NTFS filesystem implementation, stemming from improper synchronization of runlist operations. By failing to acquire the necessary runlist write lock during attribute shrinking and cluster freeing processes, the kernel exposes the filesystem to memory corruption and inconsistent on-disk state. An attacker capable of triggering specific NTFS filesystem operations could exploit this lack of serialization to cause kernel panics, potential memory disclosure, or filesystem-level denial-of-service. The flaw impacts the legacy NTFS driver within the Linux kernel. Successful exploitation requires an attacker to have local access to mount or interact with a maliciously crafted NTFS volume. Given the nature of kernel-level race conditions, the primary risk involves system instability or the potential for local privilege escalation if the memory corruption can be reliably controlled to overwrite critical kernel structures.",
  "technicalDetails": "The root cause of this vulnerability lies in the improper handling of internal runlist structures in the Linux kernel NTFS driver. Specifically, the function ntfs_non_resident_attr_shrink() performs modifications to the runlist—including freeing clusters and performing truncations—without the mandatory acquisition of the runlist write lock. In the Linux kernel's NTFS implementation, the runlist acts as the primary data structure for mapping virtual cluster numbers (VCNs) to logical cluster numbers (LCNs) on the disk. Concurrent access to this structure by different kernel threads without proper synchronization leads to race conditions.\nDuring the execution of ntfs_non_resident_attr_shrink(), the lack of a write lock allows simultaneous operations to potentially modify or read an inconsistent state of the runlist. This is further exacerbated during ntfs_attr_map_cluster() operations, where a newly allocated run may be merged into the in-memory runlist before the corresponding on-disk mapping pairs are updated. If the update fails, the kernel attempts to roll back the changes by restoring the in-memory runlist and on-disk mapping pairs from a previous saved state. However, the initial absence of locking mechanisms means that other threads could have already accessed or modified the inconsistent runlist, rendering the rollback process insufficient or resulting in further corruption.\nThe exploitation flow involves mounting a crafted NTFS filesystem and triggering specific attribute modifications. An attacker can initiate high-frequency calls that stress the attribute management code, forcing the kernel to handle concurrent shrinks and cluster allocations. Because the internal state is not protected, a thread might observe a partial update of the runlist, leading to an out-of-bounds access or a use-after-free scenario when the kernel attempts to free clusters based on corrupted runlist entries. The post-exploitation impact includes the triggering of a kernel panic (Denial of Service), or theoretically, the manipulation of the kernel heap if the race condition is sufficiently timed to allow arbitrary memory writes through the corrupted filesystem metadata. The vulnerability exists within the kernel's memory management for NTFS volumes and remains active until the serialization logic is strictly enforced via the runlist lock as described in the patch."
}