CVE-2026-72203 json
ntfs: skip extent mft records in writeback to prevent deadlock
published 2026-08-15 2 mo ago modified 2026-10-30 9 d ago also EUVD-2026-58961
- cvss
- 7.5
- version 3.1, CNA
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- 0.6%
- EPSS 0.6% chance of exploitation in 30 days, percentile 50%
- public exploits
- 0
- none known
Summary
In the Linux kernel, the following vulnerability has been resolved:
ntfs: skip extent mft records in writeback to prevent deadlock
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.
Patch / fix
- Linux Linux 6.1.191, 6.6.160, 7.1.5, 7.2
- linux Debian 14 7.1.5-1
debian advisories DEBIAN-CVE-2026-72203
- git.kernel.org/stable/c/b06b4fc2138ded8ee0b3dc602991ff6dbb10dd0a commit
- git.kernel.org/stable/c/6626fb859f4c4772f2f59751d23937716e03f98f commit
- git.kernel.org/stable/c/7ffa8f3d30236e0ab897c30bdb01224ff1fe1c89 commit
- git.kernel.org/stable/c/f831ab09d521898bf1dd99bf5adfd630ea1428e3 commit
- git.kernel.org/stable/c/76bc14c7097ff678b2b5dbfd4fa33b46897d87ce commit
Vendor advisories
What the vendors themselves say about their products: affected, fixed or not affected, and what to do.
red hat product security vex CVE-2026-72203 updated cvss 5.5
kernel: ntfs: skip extent mft records in writeback to prevent deadlock
-
Red Hat Enterprise Linux 6 perf, kernel, python-perf, kernel-kdump, kernel-firmware, kernel-bootwrapper, +1 more Red Hat Enterprise Linux 7 perf, kernel, bpftool, kernel-rt, python-perf, kernel-kdump, +8 more Red Hat Enterprise Linux 8 perf, kernel, bpftool, kernel-rt, kernel-core, kernel-tools, +29 more Red Hat Enterprise Linux 9 rv, perf, rtla, kernel, bpftool, libperf, +83 more Red Hat Enterprise Linux 10 kernelnot affected: vulnerable code not present
Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf
Exploit prediction
0.63% chance of exploitation in the next 30 days, higher than 50% of all scored CVEs (FIRST EPSS, 2026-11-08).
CVSS scores
| assigned by | version | score | vector |
|---|---|---|---|
| CNA | 3.1 | 7.5 | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H |
Affected products
- Linux Linux
Classification
- Technology feeds
References
- git.kernel.org /stable/c/b06b4fc2138ded8ee0b3dc602991ff6dbb10dd0a
- git.kernel.org /stable/c/6626fb859f4c4772f2f59751d23937716e03f98f
- git.kernel.org /stable/c/7ffa8f3d30236e0ab897c30bdb01224ff1fe1c89
- git.kernel.org /stable/c/f831ab09d521898bf1dd99bf5adfd630ea1428e3
- git.kernel.org /stable/c/76bc14c7097ff678b2b5dbfd4fa33b46897d87ce
Sources
- CVE List CVE-2026-72203
- NVD CVE-2026-72203
Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.