CVE-2026-72203

High

Description

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.

SeverityHigh
CVSS7.5
Exploit probability—
ProductLinux
PublishedAug 15, 2026
First seenAug 15, 2026

How to fix

Update
  • Linux Linuxb06b4fc2138ded8ee0b3dc602991ff6dbb10dd0a, 6626fb859f4c4772f2f59751d23937716e03f98f, 7ffa8f3d30236e0ab897c30bdb01224ff1fe1c89, f831ab09d521898bf1dd99bf5adfd630ea1428e3, 76bc14c7097ff678b2b5dbfd4fa33b46897d87ce or later

Affected products

ProductAffected versionsFixed in
Linux Linux1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 ≤ v < b06b4fc2138ded8ee0b3dc602991ff6dbb10dd0a, 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 ≤ v < 6626fb859f4c4772f2f59751d23937716e03f98f, 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 ≤ v < 7ffa8f3d30236e0ab897c30bdb01224ff1fe1c89, 1e9ea7e04472d4e5e12e58c881eaacfb3e49b669 ≤ v < f831ab09d521898bf1dd99bf5adfd630ea1428e3, 1e9ea7e04472d4e5e12e58c881eaacfb3e49b669 ≤ v < 76bc14c7097ff678b2b5dbfd4fa33b46897d87ce, 2.6.12, 7.1b06b4fc2138ded8ee0b3dc602991ff6dbb10dd0a, 6626fb859f4c4772f2f59751d23937716e03f98f, 7ffa8f3d30236e0ab897c30bdb01224ff1fe1c89, f831ab09d521898bf1dd99bf5adfd630ea1428e3, 76bc14c7097ff678b2b5dbfd4fa33b46897d87ce

Check your version

Choose the product and enter the version you run to see whether it falls in the affected range.

In the Intelligence 360 plan

Attack Surface Management

See the assets tied to your domains, the technologies they run and known vulnerabilities in one list.