Look up another CVE · open CVE-2026-72198 in the interactive tracker
CVE-2026-72198
ntfs: reject non-resident records for resident-only attributes
Published 2026-08-15 (2 months ago) by the Linux kernel CNA. Subsystem fs/ntfs. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-72198 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | won't fix | 6.1.190-1 | Debian has decided against an update for bookworm: NTFS_FS support disabled. Moving to a newer release is the way to get the fix. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
The shared lookup-time attribute validator rejects non-resident $FILE_NAME and $VOLUME_NAME records because their formats require resident values and callers handle returned records as resident attributes. Other resident-only attribute types still pass through the generic non-resident mapping-pairs checks. That leaves real resident/non-resident union confusion paths. Inode load looks up $STANDARD_INFORMATION and then reads data.resident.value_offset without checking a->non_resident. ntfs_inode_sync_standard_information() does the same when updating the standard information value. ntfs_write_volume_flags() also looks up $VOLUME_INFORMATION and reads data.resident.value_offset directly. $INDEX_ROOT callers in dir.c and index.c depend on the same lookup contract before consuming the resident index root value. Reject non-resident records for all resident-only attribute types in the shared validator. Keep the existing $FILE_NAME and $VOLUME_NAME behavior, but factor it through a helper and extend it to $STANDARD_INFORMATION, $OBJECT_ID, $VOLUME_INFORMATION, $INDEX_ROOT, and $EA_INFORMATION. For $OBJECT_ID and $EA_INFORMATION this is contract hardening for resident-only formats; this patch only rejects the non-resident form and does not add new resident value validation for those types.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
fs/ntfs/attrib.c
- What this is
- NTFS FILESYSTEMMAINTAINERS section matched on fs/ntfs/ · linux-fsdevel@vger.kernel.org · Maintained
- Kernel module
- ntfs
Check it on the machine
grep -w CONFIG_NTFS_FS /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w ntfsPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian does not build this code in 1 release. It does build it in 2 releases, so the answer depends on which release the machine runs. The build rule could not be established for 1 release, so nothing is claimed about those.
- bookwormn
- trixie?
- forky, sidm
- n
- not enabled on any flavour - this release does not build the code
- ?
- not established - no Makefile entry for the affected file
- m
- a loadable module on every flavour - check lsmod, can be blacklisted
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
- Build switch
- CONFIG_NTFS_FS
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-08-15 (2 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.17%, higher than 6.3% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- fs/ntfs
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 2.6.12 | 6.9 | 7ffa8f3d3023 |
| 7.1 | 7.1.5 | b54c9beb90e5 |
| 7.1 | 7.2 | 097cdfd0a55d |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The bug is in the in-kernel NTFS filesystem driver parsing on-disk MFT attribute records from a block device; exploitation requires mounting or accessing a crafted NTFS image via local syscalls (mount/fsopen), not remote network packet handling.
- AC:LAttack complexity, low
- An attacker fully controls crafted NTFS metadata and can reliably mark resident-only attributes (e.g. $STANDARD_INFORMATION) as non-resident with attacker-chosen union fields that pass generic non-resident validation, deterministically triggering resident/non-resident type confusion.
- PR:LPrivileges required, low
- Reaching the vulnerable ntfs_attr_lookup/ntfs_read_locked_inode paths requires mounting the filesystem (CAP_SYS_ADMIN), which unprivileged attackers can obtain in a user+mount namespace on typical Linux configurations without real init-namespace root.
- UI:NUser interaction, none
- No victim interaction is required when the attacker mounts their own malicious NTFS image (e.g. loop device) inside a user namespace; inode load and writeback then parse the poisoned attributes automatically during normal filesystem operations.
- S:UScope, unchanged
- Exploitation corrupts kernel memory and can yield local privilege escalation within the same kernel/host security boundary; it does not inherently cross VM, container, or IOMMU isolation boundaries on its own.
- C:HConfidentiality impact, high
- Callers such as ntfs_read_locked_inode() dereference data.resident.value_offset on attributes validated as non-resident, interpreting non-resident union bytes as a resident offset and performing out-of-bounds reads of MFT/kernel memory controllable by the attacker.
- I:HIntegrity impact, high
- Write paths including ntfs_inode_sync_standard_information() and ntfs_write_volume_flags() use the same misinterpreted resident offset to write standard-information and volume-information fields, giving attacker-influenced out-of-bounds kernel memory writes and type-confusion primitives.
- A:HAvailability impact, high
- Malformed resident/non-resident metadata can cause kernel oops/panics during inode load, directory traversal, or inode sync on mount and routine file activity, and memory corruption can crash or hang the system even before full exploitation.