Look up another CVE · open CVE-2026-72203 in the interactive tracker

CVE-2026-72203

ntfs: skip extent mft records in writeback to prevent deadlock

7.5 EPSS 0.6% AV:N

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-72203 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

This patch fixes the ABBA deadlock between extent_lock and extent mrec_lock triggered by xfstests generic/113, that occurs since the commit 6994acf33bae ("ntfs: use base mft_no when looking up base inode for extent record"). Path A (inode writeback): VFS writeback -> ntfs_write_inode() -> __ntfs_write_inode() -> mutex_lock(&ni->extent_lock) -> mutex_lock(&tni->mrec_lock) Path B (MFT folio writeback): VFS writeback of $MFT dirty folios -> ntfs_mft_writepages() -> ntfs_write_mft_block() -> ntfs_may_write_mft_record() -> holds one extent mrec_lock from a previous iteration -> tries to acquire another base inode extent_lock By removing all extent_lock and extent mrec_lock acquisition from the MFT folio writeback path, the ABBA lock ordering is eliminated: Path A: __ntfs_write_inode(): extent_lock -> mrec_lock Path B (removed): ntfs_write_mft_block(): mrec_lock -> extent_lock Path B is always redundant for extent records because: 1. mark_mft_record_dirty(ext_ni) does NOT dirty the MFT folio. It only sets NInoDirty(ext_ni) and marks the base VFS inode dirty via __mark_inode_dirty(I_DIRTY_DATASYNC), which triggers Path A. Therefore, normal extent modifications never create a situation where the MFT folio is dirty and Path B is not scheduled. 2. The MFT folio only gets dirtied via ntfs_mft_mark_dirty() inside ntfs_mft_record_alloc(). But all identified callers in attrib.c (ntfs_attr_add, ntfs_attr_record_move_away, ntfs_attr_make_non_resident, ntfs_attr_record_resize) follow through with mark_mft_record_dirty(), which triggers Path A to write the complete record. 3. ntfs_evict_big_inode() calls ntfs_commit_inode() before freeing extent inodes, ensuring all dirty extents are flushed via Path A before the base inode leaves the icache.

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/mft.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 ntfs

Prints 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

Debian tracker CVE record NVD kernel CNA record

Signals

Published: 2026-08-15 (2 months ago)source
CVSS: 7.5 high
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:Hsource recompute it
Attack vector: network (AV:N)source
EPSS: 0.61%, higher than 48.1% 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	f831ab09d521
7.1	7.2	76bc14c7097f

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:NAttack vector, network: The ABBA deadlock is reachable through concurrent VFS writeback on an rw-mounted NTFS volume; ntfs registers ntfs_export_ops, so nfsd/ksmbd remote WRITE/CLOSE/fsync RPCs on an exported NTFS share hit __ntfs_write_inode() and ntfs_mft_writepages() the same as local aio/write syscalls.
AC:LAttack complexity, low: xfstests generic/113 (aio-stress with concurrent O_DIRECT/O_SYNC writes) reliably reproduces the hang; an attacker controls both lock-order participants by issuing parallel file metadata writes and sync/writeback pressure without races or attacker-independent memory layout.
PR:NPrivileges required, none: Exploitation needs only write access to an rw-mounted or NFS/SMB-exported NTFS volume to drive ntfs_mft_record_alloc and concurrent writeback; no CAP_SYS_ADMIN, root, or init-namespace privileges on the server are required to deadlock the writeback paths.
UI:NUser interaction, none: Once an NTFS volume is rw-mounted (dual-boot partition, removable media, loop mount, or network export), the attacker issues the concurrent writes itself; no additional victim clicks, opens, or cooperative actions are required beyond that standing configuration.
S:UScope, unchanged: The circular mutex wait between extent_lock and extent mrec_lock only hangs kernel writeback and I/O worker threads within the host kernel security authority; it does not cross VM, container, IOMMU, or other security-boundary scopes.
C:NConfidentiality impact, none: This is a deterministic lock-order inversion with no out-of-bounds access, use-after-free, or information disclosure; blocked threads wait on mutexes without reading attacker-controlled freed memory or leaking kernel pointers.
I:NIntegrity impact, none: The defect prevents completion of metadata writeback by deadlocking mutex acquisition; it does not perform attacker-controlled memory writes, corrupt on-disk NTFS structures, or provide a metadata modification primitive beyond denying forward progress.
A:HAvailability impact, high: The ABBA deadlock between inode writeback (extent_lock then extent mrec_lock) and $MFT folio writeback (held mrec_lock then extent_lock) hangs kworker writeback and sync/fsync callers indefinitely, causing system-wide I/O denial of service.