CVE-2026-53122

MEDIUMNVD 5.55.5
EchelonGraph scoreMEDIUM confidence

Score 5.5 from GitHub Security Advisory published 2026-06-24. NVD baseline CVSS 5.5; sources differ by 0.0.

Triggered by: GitHub Security Advisory CVSS
Sources: epss, ghsa, nvd
Trending — 5 sources updated this week
5.5EG
EchelonGraph verdictMonitorLow exploitation likelihood right now — keep watching.
  • Lower severity and no public exploit yet
CISA-KEV: Not listedEPSS PROB: 0%CVSS: 5.5Exploit: None knownExposed: 0

A fix is available — apply it.

In the Linux kernel, the following vulnerability has been resolved:

btrfs: fix deadlock between reflink and transaction commit when using flushoncommit

When using the flushoncommit mount option, we can have a deadlock between a transaction commit and a reflink operation that copied an inline extent to an offset beyond the current i_size of the destination node.

The deadlock happens like this:

1) Task A clones an inline extent from inode X to an offset of inode Y that is beyond Y's current i_size. This means we copied the inline extent's data to a folio of inode Y that is beyond its EOF, using a call to copy_inline_to_page();

2) Task B starts a transaction commit and calls btrfs_start_delalloc_flush() to flush delalloc;

3) The delalloc flushing sees the new dirty folio of inode Y and when it attempts to flush it, it ends up at extent_writepage() and sees that the offset of the folio is beyond the i_size of inode Y, so it attempts to invalidate the folio by calling folio_invalidate(), which ends up at btrfs' folio invalidate callback - btrfs_invalidate_folio(). There it tries to lock the folio's range in inode Y's extent io tree, but it blocks since it's currently locked by task A - during a reflink we lock the inodes and the source and destination ranges after flushing all delalloc and waiting for ordered extent completion - after that we don't expect to have dirty folios in the ranges, the exception is if we have to copy an inline extent's data (because the destination offset is not zero);

4) Task A then attempts to start a transaction to update the inode item, and then it's blocked since the current transaction is in the TRANS_STATE_COMMIT_START state. Therefore task A has to wait for the current transaction to become unblocked (its state >= TRANS_STATE_UNBLOCKED).

So task A is waiting for the transaction commit done by task B, and the later waiting on the extent lock of inode Y that is currently held by task A.

Syzbot recently reported this with the following stack traces:

INFO: task kworker/u8:7:1053 blocked for more than 143 seconds. Not tainted syzkaller #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u8:7 state:D stack:23520 pid:1053 tgid:1053 ppid:2 task_flags:0x4208060 flags:0x00080000 Workqueue: writeback wb_workfn (flush-btrfs-46) Call Trace: context_switch kernel/sched/core.c:5298 [inline] __schedule+0x1553/0x5240 kernel/sched/core.c:6911 __schedule_loop kernel/sched/core.c:6993 [inline] schedule+0x164/0x360 kernel/sched/core.c:7008 wait_extent_bit fs/btrfs/extent-io-tree.c:811 [inline] btrfs_lock_extent_bits+0x59c/0x700 fs/btrfs/extent-io-tree.c:1914 btrfs_lock_extent fs/btrfs/extent-io-tree.h:152 [inline] btrfs_invalidate_folio+0x43d/0xc40 fs/btrfs/inode.c:7704 extent_writepage fs/btrfs/extent_io.c:1852 [inline] extent_write_cache_pages fs/btrfs/extent_io.c:2580 [inline] btrfs_writepages+0x12ff/0x2440 fs/btrfs/extent_io.c:2713 do_writepages+0x32e/0x550 mm/page-writeback.c:2554 __writeback_single_inode+0x133/0x11a0 fs/fs-writeback.c:1750 writeback_sb_inodes+0x995/0x19d0 fs/fs-writeback.c:2042 wb_writeback+0x456/0xb70 fs/fs-writeback.c:2227 wb_do_writeback fs/fs-writeback.c:2374 [inline] wb_workfn+0x41a/0xf60 fs/fs-writeback.c:2414 process_one_work kernel/workqueue.c:3276 [inline] process_scheduled_works+0xb6e/0x18c0 kernel/workqueue.c:3359 worker_thread+0xa53/0xfc0 kernel/workqueue.c:3440 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 INFO: task syz.4.64:6910 blocked for more than 143 seconds. Not tainted syzkaller #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:syz.4.64 state:D stack:22752 pid:6910 tgid: ---truncated---

CVSS v3
5.5
EG Score
5.5(medium)
EG Risk
29(Track)
EG Risk 29/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
Severity55% × 45%
Exploitation0% × 40%
Automatability30% × 15%
Action: Routine — remediate on your standard cadence.
EPSS PROB
0%
EPSS %ILE
1%
KEV
Not listed

Published

June 24, 2026

Last Modified

July 23, 2026

Advisory Details (4)

Auto-updated Jul 24, 2026
No patch confirmed yet.
generic

btrfs: fix deadlock between reflink and transaction commit when using flushoncommit - kernel/git/stable/linux.git - Linux kernel stable tree

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

btrfs: fix deadlock between reflink and transaction commit when using flushoncommit - kernel/git/stable/linux.git - Linux kernel stable tree

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

btrfs: fix deadlock between reflink and transaction commit when using flushoncommit - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/73be4a08306bb84f4d5d16f62cb80e1543109ffa
generic

btrfs: fix deadlock between reflink and transaction commit when using flushoncommit - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/6f0f9c0a368aa1fe078109091322d3b0632d9380

Patch Availability(15)

Patches are aggregated from vendor advisories (Red Hat, Microsoft, Cisco, GitHub) and package ecosystems (OSV, GHSA). Multiple rows for the same upstream release have been deduplicated.

Weakness Classification(1)

MITRE Common Weakness Enumeration — the root-cause categories this CVE belongs to.

All Vendor Advisories

(15)

Data Freshness Timeline

(refreshed 14× in last 7d / 53× 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-07-27 17:34 UTCEG score recompute
  2. 2026-07-27 17:34 UTCGHSA enrichment
  3. 2026-07-26 15:26 UTCEG score recompute
  4. 2026-07-26 15:26 UTCVendor advisory
  5. 2026-07-26 15:26 UTCGHSA enrichment
  6. 2026-07-26 14:54 UTCEPSS rescore
  7. 2026-07-24 14:18 UTCEPSS rescore
  8. 2026-07-23 22:13 UTCEG score recompute 5.50
  9. 2026-07-23 22:13 UTCGHSA enrichment
  10. 2026-07-23 22:11 UTCNVD updateCVSS v3 → 5.5 · severity → MEDIUM
  11. 2026-07-23 14:18 UTCEPSS rescore
  12. 2026-07-23 03:19 UTCEG score recompute
  13. 2026-07-22 14:08 UTCEPSS rescore
  14. 2026-07-21 15:25 UTCEPSS rescore
  15. 2026-07-20 17:08 UTCEPSS rescore
  16. 2026-07-19 14:31 UTCEPSS rescore
  17. 2026-07-19 14:31 UTCEPSS rescore
  18. 2026-07-19 02:29 UTCEPSS rescore
  19. 2026-07-18 10:04 UTCEPSS rescore
  20. 2026-07-16 17:03 UTCEPSS rescore
  21. 2026-07-15 16:57 UTCEPSS rescore
  22. 2026-07-15 16:57 UTCEPSS rescore
  23. 2026-07-15 06:11 UTCGHSA enrichment
  24. 2026-07-15 02:00 UTCEPSS rescore
  25. 2026-07-15 02:00 UTCEPSS rescore
Show 35 more
  1. 2026-07-13 22:31 UTCEPSS rescore
  2. 2026-07-13 06:13 UTCEPSS rescore
  3. 2026-07-13 06:13 UTCEPSS rescore
  4. 2026-07-12 07:02 UTCGHSA enrichment
  5. 2026-07-12 05:46 UTCEPSS rescore
  6. 2026-07-11 08:27 UTCEPSS rescore
  7. 2026-07-11 08:27 UTCEPSS rescore
  8. 2026-07-09 19:10 UTCEPSS rescore
  9. 2026-07-09 19:10 UTCEPSS rescore
  10. 2026-07-09 09:11 UTCGHSA enrichment
  11. 2026-07-08 15:16 UTCEPSS rescore
  12. 2026-07-08 15:16 UTCEPSS rescore
  13. 2026-07-07 13:46 UTCEPSS rescore
  14. 2026-07-07 13:46 UTCEPSS rescore
  15. 2026-07-06 11:20 UTCGHSA enrichment
  16. 2026-07-06 02:23 UTCEPSS rescore
  17. 2026-07-06 02:23 UTCEPSS rescore
  18. 2026-07-05 02:31 UTCEPSS rescore
  19. 2026-07-05 02:30 UTCEPSS rescore
  20. 2026-07-04 06:31 UTCEPSS rescore
  21. 2026-07-04 06:31 UTCEPSS rescore
  22. 2026-07-03 12:49 UTCGHSA enrichment
  23. 2026-07-01 15:07 UTCEPSS rescore
  24. 2026-06-30 23:22 UTCEPSS rescore
  25. 2026-06-30 13:49 UTCGHSA enrichment
  26. 2026-06-29 14:06 UTCEPSS rescore
  27. 2026-06-29 14:06 UTCEPSS rescore
  28. 2026-06-28 14:07 UTCEPSS rescore
  29. 2026-06-28 04:56 UTCEPSS rescore
  30. 2026-06-28 04:56 UTCEPSS rescore
  31. 2026-06-27 15:59 UTCGHSA enrichment
  32. 2026-06-27 03:08 UTCEPSS rescore
  33. 2026-06-25 13:49 UTCEPSS rescore
  34. 2026-06-24 18:08 UTCEG score recompute
  35. 2026-06-24 18:03 UTCNVD updatefirst tracked

Frequently asked(5)

What is CVE-2026-53122?
CVE-2026-53122 is a medium vulnerability published on June 24, 2026. In the Linux kernel, the following vulnerability has been resolved: btrfs: fix deadlock between reflink and transaction commit when using flushoncommit When using the flushoncommit mount option, we can have a deadlock between a transaction commit and a reflink operation that copied an inline extent…
When was CVE-2026-53122 disclosed?
CVE-2026-53122 was first published in the National Vulnerability Database on June 24, 2026, with the most recent update on July 23, 2026. EchelonGraph re-ingests CVE updates from NVD on a 2-hour cycle, so this page reflects the latest published state.
Is CVE-2026-53122 actively exploited?
CVE-2026-53122 is not currently on CISA's Known Exploited Vulnerabilities catalog. FIRST EPSS estimates a 0% probability of exploitation in the next 30 days, which ranks it in the top 99.3% of all scored CVEs.
What is the CVSS score of CVE-2026-53122?
CVE-2026-53122 has a CVSS v3 base score of 5.5 (NVD).
How do I remediate CVE-2026-53122?
Patch to the fixed version published by the affected vendor. Where vendor advisories exist for CVE-2026-53122, 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-53122

Explore →

Is Your Infrastructure Affected by CVE-2026-53122?

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