# CVE-2026-53122: btrfs: fix deadlock between reflink and transaction commit when using flushoncommit

> A deadlock in the btrfs filesystem can cause a denial of service when using the flushoncommit mount option.

- **Severity:** Medium 5.5 (`CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H`)
- **Exploited in the wild:** Not known
- **Login needed:** Any signed-in user
- **Attackable:** Local or same network only
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 24 Jun 2026
- **Updated:** 21 Oct 2026
- **Also known as:** AZL-90368, BELL-CVE-2026-53122, DEBIAN-CVE-2026-53122, GHSA-qcjh-44gv-7799, ROOT-OS-DEBIAN-11-CVE-2026-53122, ROOT-OS-DEBIAN-12-CVE-2026-53122, ROOT-OS-UBUNTU-2204-CVE-2026-53122, ROOT-OS-UBUNTU-2404-CVE-2026-53122, UBUNTU-CVE-2026-53122

## What is CVE-2026-53122?

CVE-2026-53122 is a medium-severity vulnerability in Linux kernel, published on 24 Jun 2026. It can only be exploited from the same machine or local network, with no action from the victim.

### Official description

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:
   <TASK>
   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
   </TASK>
  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---

Weakness: CWE-667 (Improper Locking)

## Which versions are affected by CVE-2026-53122?

It affects 1 product.


Products: Linux kernel.

## How do I fix CVE-2026-53122?

Apply the vendor's patch.

## Is CVE-2026-53122 being exploited?

There is no known exploitation of CVE-2026-53122 in the wild and no public exploit code.

## Other vulnerabilities in Linux kernel

- [CVE-2026-53266](https://insights.sbomify.com/CVE-2026-53266/): Linux Kernel Out-of-Bounds Write (high 8.8, exploited in the wild)
- [CVE-2013-6282](https://insights.sbomify.com/CVE-2013-6282/): Linux Kernel Improper Input Validation (high 8.8, exploited in the wild)
- [CVE-2022-0185](https://insights.sbomify.com/CVE-2022-0185/): Linux Kernel Heap-Based Buffer Overflow (high 8.4, exploited in the wild)
- [CVE-2013-2094](https://insights.sbomify.com/CVE-2013-2094/): Linux Kernel Privilege Escalation (high 8.4, exploited in the wild)
- [CVE-2026-53362](https://insights.sbomify.com/CVE-2026-53362/): Linux Kernel Unspecified (high 7.8, exploited in the wild)

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2026-53122 and fix it if it is affected.

What it is: CVE-2026-53122 is a medium-severity vulnerability in Linux kernel, published on 24 Jun 2026. It can only be exploited from the same machine or local network, with no action from the victim.
Exploitation: There is no known exploitation of CVE-2026-53122 in the wild and no public exploit code.

Affected product: Linux kernel. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2026-53122/ (Markdown: https://insights.sbomify.com/CVE-2026-53122/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2026-53122
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-53122
- OSV: https://osv.dev/vulnerability/CVE-2026-53122

---
From sbomify Insights: https://insights.sbomify.com/CVE-2026-53122/
Summaries are generated and may contain mistakes; the official description above is the record.