CVE-2026-72354

HIGHPre-NVD 8.88.8—
EchelonGraph scoreHIGH confidence

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

Triggered by: GitHub Security Advisory CVSS
Sources: epss, ghsa, secondary
Trending — 5 sources updated this week
8.8EG
EchelonGraph verdictPlan a fixSerious severity, but no confirmed exploitation yet.
  • High severity, but no confirmed exploitation yet
CISA-KEV: Not listedEPSS PROB: 1%CVSS: 8.8Exploit: 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: avoid stale runlist element dereference in MFT writeback

ntfs_write_mft_block() maps each $MFT record through the $MFT data runlist. For sub-folio clusters it looks up a struct runlist_element under ni->runlist.lock, drops the lock, and later uses rl->length and rl->vcn when choosing folio_sz.

That pointer is only borrowed from ni->runlist.rl. Concurrent $MFT allocation extension can merge a replacement runlist under the same lock, and ntfs_rl_realloc() can free the old backing array. If that happens between the lookup and the later folio_sz decision, writeback can dereference freed runlist storage.

The buggy scenario involves two paths, with each column showing the order within that path:

MFT writeback path: $MFT allocation extension:

  • Look up rl under 1. Extend the $MFT data allocation.
ni->runlist.lock. 2. Publish a replacement runlist.
  • Drop ni->runlist.lock. 3. Free the old runlist array.
  • Read rl->length and rl->vcn
to choose folio_sz.

Compute the remaining run length while ni->runlist.lock is still held, and use that scalar after unlock. This preserves the existing folio sizing decision without carrying a borrowed runlist_element across the lock boundary.

Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in ntfs_mft_writepages+0x1c8d/0x1fb0

Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 ? ntfs_mft_writepages+0x1c8d/0x1fb0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x20d/0x410 ? ntfs_mft_writepages+0x1c8d/0x1fb0 kasan_report+0xe0/0x110 ? ntfs_mft_writepages+0x1c8d/0x1fb0 ntfs_mft_writepages+0x1c8d/0x1fb0 ? __pfx_ntfs_mft_writepages+0x10/0x10 ? __pfx___mutex_unlock_slowpath+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? iput+0x92/0xa80 do_writepages+0x219/0x530 ? __pfx_do_writepages+0x10/0x10 __writeback_single_inode+0x117/0xf50 ? do_raw_spin_lock+0x130/0x270 ? __pfx_do_raw_spin_lock+0x10/0x10 ? __pfx___writeback_single_inode+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 writeback_sb_inodes+0x65b/0x1810 ? srso_alias_return_thunk+0x5/0xfbef5 ? lock_acquire+0x2b8/0x2f0 ? __pfx_writeback_sb_inodes+0x10/0x10 ? lock_release+0x1e0/0x280 ? _raw_spin_unlock+0x23/0x40 ? move_expired_inodes+0x2b8/0x850 __writeback_inodes_wb+0xf4/0x270 ? __pfx___writeback_inodes_wb+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? queue_io+0x2e4/0x410 wb_writeback+0x666/0x880 ? srso_alias_return_thunk+0x5/0xfbef5 ? __pfx_wb_writeback+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? get_nr_dirty_inodes+0x1c/0x170 wb_workfn+0x75e/0xbb0 ? srso_alias_return_thunk+0x5/0xfbef5 ? _raw_spin_unlock_irqrestore+0x27/0x60 ? __pfx_wb_workfn+0x10/0x10 ? __pfx_debug_object_deactivate+0x10/0x10 ? lock_acquire+0x2b8/0x2f0 ? srso_alias_return_thunk+0x5/0xfbef5 ? lock_release+0x1e0/0x280 process_one_work+0x8d0/0x1870 ? __pfx_process_one_work+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 worker_thread+0x575/0xf80 ? __pfx_worker_thread+0x10/0x10 kthread+0x2e7/0x3c0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x576/0x810 ? __pfx_ret_from_fork+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __switch_to+0x57e/0xe10 ? __switch_to_asm+0x33/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30

Allocated by task 970: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 __kvmalloc_node_noprof+0x353/0x920 ntfs_rl_realloc+0x3c/0x80 ntfs_runlists_merge+0x1212/0x3010 ntfs_mft_data_extend_allocation_nolock+0x3e0/0x1f40 ntfs_mft_record_alloc+0x1ab4/0x4f10 __ntfs_create+0x680/0x2e50 ntfs_create+0x1e6/0x3a0 path_openat+0x2b55/0x3c10 do_file_open+0x1f4/0x460 do_sys_openat2+0xde/0x170 __x64_sys_openat+0x122/0x1e0 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Freed by task 1294: kasan_save_ ---truncated---

CVSS v3
8.8
EG Score
8.8(high)
EG Risk
44(Track)
EG Risk 44/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
Severity88% × 45%
Exploitation1% × 40%
Automatability30% × 15%
Action: Routine — remediate on your standard cadence.
EPSS PROB
1%
EPSS %ILE
41%
KEV
Not listed

Published

August 15, 2026

Last Modified

August 17, 2026

Advisory Details (2)

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

ntfs: avoid stale runlist element dereference in MFT writeback - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/9a2e36963a3fc52401586657d34e3f1c5a01ea56
generic

ntfs: avoid stale runlist element dereference in MFT writeback - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/81fe702ff1760da32bcd3ef4494b2a33dbeced72

Vendor Advisories for CVE-2026-72354(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 30× in last 7d / 30× 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-20 22:56 UTCEPSS rescore
  2. 2026-08-20 21:17 UTCGHSA enrichment
  3. 2026-08-20 08:54 UTCGHSA enrichment
  4. 2026-08-19 20:31 UTCEG score recompute
  5. 2026-08-19 20:31 UTCGHSA enrichment
  6. 2026-08-19 17:04 UTCEPSS rescore
  7. 2026-08-19 08:08 UTCGHSA enrichment
  8. 2026-08-18 19:45 UTCEG score recompute
  9. 2026-08-18 19:45 UTCGHSA enrichment
  10. 2026-08-18 13:49 UTCEPSS rescore
  11. 2026-08-18 13:49 UTCEPSS rescore
  12. 2026-08-18 07:22 UTCGHSA enrichment
  13. 2026-08-17 18:59 UTCEG score recompute
  14. 2026-08-17 18:59 UTCGHSA enrichment
  15. 2026-08-17 13:47 UTCEPSS rescore
  16. 2026-08-17 06:29 UTCEG score recompute
  17. 2026-08-17 06:29 UTCGHSA enrichment
  18. 2026-08-17 05:58 UTCEG score recompute▲ 8.80
  19. 2026-08-17 05:58 UTCGHSA enrichment
  20. 2026-08-17 05:54 UTCMITRE cvelistV5CVSS v3 → 8.8 · severity → HIGH
  21. 2026-08-17 05:30 UTCEG score recompute
  22. 2026-08-17 05:30 UTCGHSA enrichment
  23. 2026-08-17 05:24 UTCMITRE cvelistV5
  24. 2026-08-16 14:56 UTCEPSS rescore
  25. 2026-08-16 14:56 UTCEPSS rescore
Show 5 more
  1. 2026-08-16 02:15 UTCEPSS rescore
  2. 2026-08-15 06:36 UTCGHSA enrichment
  3. 2026-08-15 06:23 UTCNVD update
  4. 2026-08-15 06:06 UTCEG score recompute
  5. 2026-08-15 06:02 UTCMITRE cvelistV5first tracked

Frequently asked(5)

What is CVE-2026-72354?
CVE-2026-72354 is a high vulnerability published on August 15, 2026. In the Linux kernel, the following vulnerability has been resolved: ntfs: avoid stale runlist element dereference in MFT writeback ntfswritemft_block() maps each $MFT record through the $MFT data runlist. For sub-folio clusters it looks up a struct runlist_element under ni->runlist.lock, drops the…
When was CVE-2026-72354 disclosed?
CVE-2026-72354 was first published in the National Vulnerability Database on August 15, 2026, with the most recent update on August 17, 2026. EchelonGraph re-ingests CVE updates from NVD on a 2-hour cycle, so this page reflects the latest published state.
Is CVE-2026-72354 actively exploited?
CVE-2026-72354 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 58.7% of all scored CVEs.
What is the CVSS score of CVE-2026-72354?
CVE-2026-72354 has a CVSS v3 base score of 8.8 (NVD).
How do I remediate CVE-2026-72354?
Patch to the fixed version published by the affected vendor. Where vendor advisories exist for CVE-2026-72354, 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-72354

Explore →

Is Your Infrastructure Affected by CVE-2026-72354?

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

Start Free Scan →Browse All CVEs