CVE-2026-72203

HIGHPre-NVD 7.57.5
EchelonGraph scoreHIGH confidence

Score 7.5 from GitHub Security Advisory (severity: HIGH) published 2026-08-15. a secondary CVSS source baseline 7.5; sources differ by 0.0.

Triggered by: GitHub Security Advisory CVSS
Sources: epss, ghsa, secondary
Trending — 5 sources updated this week
7.5EG
EchelonGraph verdictPlan a fixSerious severity, but no confirmed exploitation yet.
  • High severity, but no confirmed exploitation yet
CISA-KEV: Not listedEPSS PROB: 1%CVSS: 7.5Exploit: None knownExposed: 0

No vendor fix yet — apply a workaround or compensating control (WAF / firewall / segmentation) and watch for a patch.

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:

  • 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.
  • 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.
  • 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.

CVSS v3
7.5
EG Score
7.5(high)
EG Risk
38(Track)
EG Risk 38/100SSVC: Track

EG Risk is EchelonGraph's 0–100 priority score: it fuses intrinsic severity with real-world exploitation and automatability so you can rank equal-severity CVEs and fix the most dangerous first. Higher = act sooner. Distinct from the 0–10 EG Score (severity).

How it’s computed
Severity75% × 45%
Exploitation1% × 40%
Automatability30% × 15%
Action: Routine — remediate on your standard cadence.
EPSS PROB
1%
EPSS %ILE
45%
KEV
Not listed

Published

August 15, 2026

Last Modified

August 19, 2026

Advisory Details (2)

Auto-updated Aug 17, 2026
No patch confirmed yet.
generic

ntfs: skip extent mft records in writeback to prevent deadlock - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/f831ab09d521898bf1dd99bf5adfd630ea1428e3
generic

ntfs: skip extent mft records in writeback to prevent deadlock - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/76bc14c7097ff678b2b5dbfd4fa33b46897d87ce

Vendor Advisories for CVE-2026-72203(1)

These vendors published their own advisory mentioning this CVE — often with vendor-specific remediation steps + affected product lists not in NVD.

Data Freshness Timeline

(refreshed 41× in last 7d / 41× in last 30d)

Each row is a source pipeline that fetched or updated this CVE on that date, with what changed. For example, "NVD update" means NVD published or revised its analysis for this CVE; "MITRE cvelistV5" means we ingested or refreshed it from the CNA feed. Most recent first.

  1. 2026-08-21 04:38 UTCEG score recompute
  2. 2026-08-21 04:38 UTCGHSA enrichment
  3. 2026-08-20 22:56 UTCEPSS rescore
  4. 2026-08-20 17:32 UTCGHSA enrichment
  5. 2026-08-20 06:29 UTCGHSA enrichment
  6. 2026-08-19 19:25 UTCEG score recompute
  7. 2026-08-19 19:25 UTCGHSA enrichment
  8. 2026-08-19 17:04 UTCEPSS rescore
  9. 2026-08-19 08:21 UTCEG score recompute
  10. 2026-08-19 08:21 UTCGHSA enrichment
  11. 2026-08-19 07:48 UTCGHSA enrichment
  12. 2026-08-19 07:29 UTCEG score recompute
  13. 2026-08-19 07:29 UTCGHSA enrichment
  14. 2026-08-19 05:32 UTCGHSA enrichment
  15. 2026-08-18 18:29 UTCEG score recompute
  16. 2026-08-18 18:29 UTCGHSA enrichment
  17. 2026-08-18 13:49 UTCEPSS rescore
  18. 2026-08-18 13:49 UTCEPSS rescore
  19. 2026-08-18 07:25 UTCEG score recompute
  20. 2026-08-18 07:25 UTCGHSA enrichment
  21. 2026-08-18 07:03 UTCEG score recompute
  22. 2026-08-18 07:03 UTCGHSA enrichment
  23. 2026-08-18 04:33 UTCGHSA enrichment
  24. 2026-08-17 17:29 UTCEG score recompute
  25. 2026-08-17 17:28 UTCGHSA enrichment
Show 16 more
  1. 2026-08-17 13:47 UTCEPSS rescore
  2. 2026-08-17 06:20 UTCEG score recompute
  3. 2026-08-17 06:20 UTCGHSA enrichment
  4. 2026-08-17 06:00 UTCEG score recompute 7.50
  5. 2026-08-17 05:59 UTCGHSA enrichment
  6. 2026-08-17 05:54 UTCMITRE cvelistV5CVSS v3 → 7.5 · severity → HIGH
  7. 2026-08-17 05:32 UTCEG score recompute
  8. 2026-08-17 05:32 UTCGHSA enrichment
  9. 2026-08-17 05:25 UTCMITRE cvelistV5
  10. 2026-08-16 14:56 UTCEPSS rescore
  11. 2026-08-16 14:56 UTCEPSS rescore
  12. 2026-08-16 02:15 UTCEPSS rescore
  13. 2026-08-15 06:40 UTCGHSA enrichment
  14. 2026-08-15 06:23 UTCNVD update
  15. 2026-08-15 06:10 UTCEG score recompute
  16. 2026-08-15 06:02 UTCMITRE cvelistV5first tracked

Frequently asked(5)

What is CVE-2026-72203?
CVE-2026-72203 is a high vulnerability published on August 15, 2026. 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…
When was CVE-2026-72203 disclosed?
CVE-2026-72203 was first published in the National Vulnerability Database on August 15, 2026, with the most recent update on August 19, 2026. EchelonGraph re-ingests CVE updates from NVD on a 2-hour cycle, so this page reflects the latest published state.
Is CVE-2026-72203 actively exploited?
CVE-2026-72203 is not currently on CISA's Known Exploited Vulnerabilities catalog. FIRST EPSS estimates a 1% probability of exploitation in the next 30 days, which ranks it in the top 55.0% of all scored CVEs.
What is the CVSS score of CVE-2026-72203?
CVE-2026-72203 has a CVSS v3 base score of 7.5 (NVD).
How do I remediate CVE-2026-72203?
Patch to the fixed version published by the affected vendor. Where vendor advisories exist for CVE-2026-72203, EchelonGraph cross-links them in the Vendor Advisories panel below — those typically contain the canonical remediation steps, fixed version numbers, and any vendor-specific mitigations.

Dependency Blast Radius

Explore the affected products and dependency analysis for CVE-2026-72203

Explore →

Is Your Infrastructure Affected by CVE-2026-72203?

EchelonGraph automatically scans your cloud infrastructure and maps CVE exposure using blast radius analysis.