In the Linux kernel, the following vulnerability has been resolved:
ntfs: fix WARN_ON for resident attribute in ntfs_map_runlist_nolock()
When ntfs_map_runlist_nolock() needs to look up the attribute extent
containing a target VCN (ctx_needs_reset == true), it calls
ntfs_attr_lookup() and then expects the result to be a non-resident
attribute, since only non-resident attributes have a mapping pairs
array to decompress.
A crafted NTFS image can place a resident attribute where a non-resident
one is expected, causing ntfs_attr_lookup() to succeed but return a
resident attribute record. Previously this was caught only by a
WARN_ON(), which does not stop execution. The code then falls through to
read a->data.non_resident.highest_vcn from what is actually a resident
attribute, accessing the wrong union member and corrupting the VCN range
check.
The caller path triggering this warning during mount is:
ntfs_map_runlist_nolock
ntfs_empty_logfile
load_system_files
ntfs_fill_super
In this path ctx is NULL, so ntfs_map_runlist_nolock() allocates a
temporary search context internally and sets ctx_needs_reset = true.
The existing resident-attribute guard in the ctx != NULL branch already
returns -EIO silently for the same condition; make the ctx_needs_reset
path consistent by replacing the WARN_ON() with the same -EIO error
return.
This causes the crafted image to be rejected with a mount error instead
of triggering a kernel warning.
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 9.8
AV:N - The bug is in fs/ntfs runlist mapping reached from ntfs_fill_super→ntfs_empty_logfile on mount and from VFS read/iomap paths (ntfs_attr_vcn_to_rl→ntfs_map_runlist_nolock); when a classic NTFS volume is exported via ksmbd or nfsd, a remote client read triggers the same mapping code on the server without local shell access.
AC:L - An attacker fully controls the crafted NTFS image: placing a resident $DATA extent where a non-resident one is expected makes ntfs_attr_lookup() succeed, bypasses the old WARN_ON-only guard, and deterministically drives the wrong union reads and mapping-pairs decompression with no races or victim-specific memory layout.
PR:N - Exploitation needs only a malicious NTFS image and access to have it parsed—no root on the target—via udev/systemd automount of attacker USB media, CAP_SYS_ADMIN mount of a loop image, or a remote ksmbd/nfsd client with guest/anonymous read (or write) on an already-exported NTFS share.
UI:N - Once the crafted volume is mounted (automounter, admin, or server export), a single attacker-initiated mount or remote file read that maps an affected non-resident extent triggers the bug; no further victim clicks, prompts, or confirmation are required beyond supplying the image.
S:U - Union confusion and forged runlist handling corrupt kernel heap metadata and can issue attacker-influenced block-device writes within the same host OS security domain; impact is local privilege escalation or disk corruption, not VM/hypervisor, IOMMU, or container sandbox escape.
C:H - WARN_ON does not stop execution; the code reads non_resident.highest_vcn and mapping_pairs_offset from a resident attribute union, then ntfs_mapping_pairs_decompress() scans attacker-controlled bytes as mapping pairs, yielding out-of-bounds kernel reads and disclosure/corruption primitives beyond a simple warning.
I:H - Successful decompression installs an attacker-forged runlist; on rw mount ntfs_empty_logfile() uses those LCNs to write 0xff-filled clusters via ntfs_bdev_write() to arbitrary disk offsets, and heap runlist allocation from forged mapping pairs enables arbitrary kernel memory corruption and potential control-flow hijack.
A:H - The vulnerable path continues after WARN_ON instead of returning -EIO, so malformed mapping-pair decompression and use of a corrupted runlist can provoke kernel warnings, I/O errors, oops, or panic during mount or subsequent NTFS I/O, causing high availability impact even when full exploitation is not attempted.
| Attack Vector |
Network |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
None |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:N - The bug is in fs/ntfs runlist mapping reached from ntfs_fill_super→ntfs_empty_logfile on mount and from VFS read/iomap paths (ntfs_attr_vcn_to_rl→ntfs_map_runlist_nolock); when a classic NTFS volume is exported via ksmbd or nfsd, a remote client read triggers the same mapping code on the server without local shell access.
AC:L - An attacker fully controls the crafted NTFS image: placing a resident $DATA extent where a non-resident one is expected makes ntfs_attr_lookup() succeed, bypasses the old WARN_ON-only guard, and deterministically drives the wrong union reads and mapping-pairs decompression with no races or victim-specific memory layout.
PR:N - Exploitation needs only a malicious NTFS image and access to have it parsed—no root on the target—via udev/systemd automount of attacker USB media, CAP_SYS_ADMIN mount of a loop image, or a remote ksmbd/nfsd client with guest/anonymous read (or write) on an already-exported NTFS share.
UI:N - Once the crafted volume is mounted (automounter, admin, or server export), a single attacker-initiated mount or remote file read that maps an affected non-resident extent triggers the bug; no further victim clicks, prompts, or confirmation are required beyond supplying the image.
S:U - Union confusion and forged runlist handling corrupt kernel heap metadata and can issue attacker-influenced block-device writes within the same host OS security domain; impact is local privilege escalation or disk corruption, not VM/hypervisor, IOMMU, or container sandbox escape.
C:H - WARN_ON does not stop execution; the code reads non_resident.highest_vcn and mapping_pairs_offset from a resident attribute union, then ntfs_mapping_pairs_decompress() scans attacker-controlled bytes as mapping pairs, yielding out-of-bounds kernel reads and disclosure/corruption primitives beyond a simple warning.
I:H - Successful decompression installs an attacker-forged runlist; on rw mount ntfs_empty_logfile() uses those LCNs to write 0xff-filled clusters via ntfs_bdev_write() to arbitrary disk offsets, and heap runlist allocation from forged mapping pairs enables arbitrary kernel memory corruption and potential control-flow hijack.
A:H - The vulnerable path continues after WARN_ON instead of returning -EIO, so malformed mapping-pair decompression and use of a corrupted runlist can provoke kernel warnings, I/O errors, oops, or panic during mount or subsequent NTFS I/O, causing high availability impact even when full exploitation is not attempted.
CVSS 3.1