{"api_version":"1","generated_at":"2026-06-24T19:26:36+00:00","cve":"CVE-2026-53122","urls":{"html":"https://cve.report/CVE-2026-53122","api":"https://cve.report/api/cve/CVE-2026-53122.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-53122","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-53122"},"summary":{"title":"btrfs: fix deadlock between reflink and transaction commit when using flushoncommit","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix deadlock between reflink and transaction commit when using flushoncommit\n\nWhen using the flushoncommit mount option, we can have a deadlock between\na transaction commit and a reflink operation that copied an inline extent\nto an offset beyond the current i_size of the destination node.\n\nThe deadlock happens like this:\n\n1) Task A clones an inline extent from inode X to an offset of inode Y\n   that is beyond Y's current i_size. This means we copied the inline\n   extent's data to a folio of inode Y that is beyond its EOF, using a\n   call to copy_inline_to_page();\n\n2) Task B starts a transaction commit and calls\n   btrfs_start_delalloc_flush() to flush delalloc;\n\n3) The delalloc flushing sees the new dirty folio of inode Y and when it\n   attempts to flush it, it ends up at extent_writepage() and sees that\n   the offset of the folio is beyond the i_size of inode Y, so it attempts\n   to invalidate the folio by calling folio_invalidate(), which ends up at\n   btrfs' folio invalidate callback - btrfs_invalidate_folio(). There it\n   tries to lock the folio's range in inode Y's extent io tree, but it\n   blocks since it's currently locked by task A - during a reflink we lock\n   the inodes and the source and destination ranges after flushing all\n   delalloc and waiting for ordered extent completion - after that we\n   don't expect to have dirty folios in the ranges, the exception is if\n   we have to copy an inline extent's data (because the destination offset\n   is not zero);\n\n4) Task A then attempts to start a transaction to update the inode item,\n   and then it's blocked since the current transaction is in the\n   TRANS_STATE_COMMIT_START state. Therefore task A has to wait for the\n   current transaction to become unblocked (its state >=\n   TRANS_STATE_UNBLOCKED).\n\n   So task A is waiting for the transaction commit done by task B, and\n   the later waiting on the extent lock of inode Y that is currently\n   held by task A.\n\nSyzbot recently reported this with the following stack traces:\n\n  INFO: task kworker/u8:7:1053 blocked for more than 143 seconds.\n        Not tainted syzkaller #0\n  \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n  task:kworker/u8:7    state:D stack:23520 pid:1053  tgid:1053  ppid:2      task_flags:0x4208060 flags:0x00080000\n  Workqueue: writeback wb_workfn (flush-btrfs-46)\n  Call Trace:\n   <TASK>\n   context_switch kernel/sched/core.c:5298 [inline]\n   __schedule+0x1553/0x5240 kernel/sched/core.c:6911\n   __schedule_loop kernel/sched/core.c:6993 [inline]\n   schedule+0x164/0x360 kernel/sched/core.c:7008\n   wait_extent_bit fs/btrfs/extent-io-tree.c:811 [inline]\n   btrfs_lock_extent_bits+0x59c/0x700 fs/btrfs/extent-io-tree.c:1914\n   btrfs_lock_extent fs/btrfs/extent-io-tree.h:152 [inline]\n   btrfs_invalidate_folio+0x43d/0xc40 fs/btrfs/inode.c:7704\n   extent_writepage fs/btrfs/extent_io.c:1852 [inline]\n   extent_write_cache_pages fs/btrfs/extent_io.c:2580 [inline]\n   btrfs_writepages+0x12ff/0x2440 fs/btrfs/extent_io.c:2713\n   do_writepages+0x32e/0x550 mm/page-writeback.c:2554\n   __writeback_single_inode+0x133/0x11a0 fs/fs-writeback.c:1750\n   writeback_sb_inodes+0x995/0x19d0 fs/fs-writeback.c:2042\n   wb_writeback+0x456/0xb70 fs/fs-writeback.c:2227\n   wb_do_writeback fs/fs-writeback.c:2374 [inline]\n   wb_workfn+0x41a/0xf60 fs/fs-writeback.c:2414\n   process_one_work kernel/workqueue.c:3276 [inline]\n   process_scheduled_works+0xb6e/0x18c0 kernel/workqueue.c:3359\n   worker_thread+0xa53/0xfc0 kernel/workqueue.c:3440\n   kthread+0x388/0x470 kernel/kthread.c:436\n   ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158\n   ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245\n   </TASK>\n  INFO: task syz.4.64:6910 blocked for more than 143 seconds.\n        Not tainted syzkaller #0\n  \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n  task:syz.4.64        state:D stack:22752 pid:6910  tgid:\n---truncated---","state":"PUBLISHED","assigner":"Linux","published_at":"2026-06-24 17:17:26","updated_at":"2026-06-24 17:17:26"},"problem_types":[],"metrics":[],"references":[{"url":"https://git.kernel.org/stable/c/b48c980b6a7e409050bb3067165db31cc6205e3e","name":"https://git.kernel.org/stable/c/b48c980b6a7e409050bb3067165db31cc6205e3e","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/73be4a08306bb84f4d5d16f62cb80e1543109ffa","name":"https://git.kernel.org/stable/c/73be4a08306bb84f4d5d16f62cb80e1543109ffa","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/9a24f0000876b8755cf21972b41632f4d6f3dafb","name":"https://git.kernel.org/stable/c/9a24f0000876b8755cf21972b41632f4d6f3dafb","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/6f0f9c0a368aa1fe078109091322d3b0632d9380","name":"https://git.kernel.org/stable/c/6f0f9c0a368aa1fe078109091322d3b0632d9380","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-53122","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53122","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 05a5a7621ce66c142e081ffc24dd6ade6e912061 73be4a08306bb84f4d5d16f62cb80e1543109ffa git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 05a5a7621ce66c142e081ffc24dd6ade6e912061 9a24f0000876b8755cf21972b41632f4d6f3dafb git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 05a5a7621ce66c142e081ffc24dd6ade6e912061 6f0f9c0a368aa1fe078109091322d3b0632d9380 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 05a5a7621ce66c142e081ffc24dd6ade6e912061 b48c980b6a7e409050bb3067165db31cc6205e3e git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 5.7","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 5.7 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.12.91 6.12.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.18.33 6.18.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.0.10 7.0.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.1 * original_commit_for_fix","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"defaultStatus":"unaffected","product":"Linux","programFiles":["fs/btrfs/reflink.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThan":"73be4a08306bb84f4d5d16f62cb80e1543109ffa","status":"affected","version":"05a5a7621ce66c142e081ffc24dd6ade6e912061","versionType":"git"},{"lessThan":"9a24f0000876b8755cf21972b41632f4d6f3dafb","status":"affected","version":"05a5a7621ce66c142e081ffc24dd6ade6e912061","versionType":"git"},{"lessThan":"6f0f9c0a368aa1fe078109091322d3b0632d9380","status":"affected","version":"05a5a7621ce66c142e081ffc24dd6ade6e912061","versionType":"git"},{"lessThan":"b48c980b6a7e409050bb3067165db31cc6205e3e","status":"affected","version":"05a5a7621ce66c142e081ffc24dd6ade6e912061","versionType":"git"}]},{"defaultStatus":"affected","product":"Linux","programFiles":["fs/btrfs/reflink.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"status":"affected","version":"5.7"},{"lessThan":"5.7","status":"unaffected","version":"0","versionType":"semver"},{"lessThanOrEqual":"6.12.*","status":"unaffected","version":"6.12.91","versionType":"semver"},{"lessThanOrEqual":"6.18.*","status":"unaffected","version":"6.18.33","versionType":"semver"},{"lessThanOrEqual":"7.0.*","status":"unaffected","version":"7.0.10","versionType":"semver"},{"lessThanOrEqual":"*","status":"unaffected","version":"7.1","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.12.91","versionStartIncluding":"5.7","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.18.33","versionStartIncluding":"5.7","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.0.10","versionStartIncluding":"5.7","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.1","versionStartIncluding":"5.7","vulnerable":true}],"negate":false,"operator":"OR"}]}],"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix deadlock between reflink and transaction commit when using flushoncommit\n\nWhen using the flushoncommit mount option, we can have a deadlock between\na transaction commit and a reflink operation that copied an inline extent\nto an offset beyond the current i_size of the destination node.\n\nThe deadlock happens like this:\n\n1) Task A clones an inline extent from inode X to an offset of inode Y\n   that is beyond Y's current i_size. This means we copied the inline\n   extent's data to a folio of inode Y that is beyond its EOF, using a\n   call to copy_inline_to_page();\n\n2) Task B starts a transaction commit and calls\n   btrfs_start_delalloc_flush() to flush delalloc;\n\n3) The delalloc flushing sees the new dirty folio of inode Y and when it\n   attempts to flush it, it ends up at extent_writepage() and sees that\n   the offset of the folio is beyond the i_size of inode Y, so it attempts\n   to invalidate the folio by calling folio_invalidate(), which ends up at\n   btrfs' folio invalidate callback - btrfs_invalidate_folio(). There it\n   tries to lock the folio's range in inode Y's extent io tree, but it\n   blocks since it's currently locked by task A - during a reflink we lock\n   the inodes and the source and destination ranges after flushing all\n   delalloc and waiting for ordered extent completion - after that we\n   don't expect to have dirty folios in the ranges, the exception is if\n   we have to copy an inline extent's data (because the destination offset\n   is not zero);\n\n4) Task A then attempts to start a transaction to update the inode item,\n   and then it's blocked since the current transaction is in the\n   TRANS_STATE_COMMIT_START state. Therefore task A has to wait for the\n   current transaction to become unblocked (its state >=\n   TRANS_STATE_UNBLOCKED).\n\n   So task A is waiting for the transaction commit done by task B, and\n   the later waiting on the extent lock of inode Y that is currently\n   held by task A.\n\nSyzbot recently reported this with the following stack traces:\n\n  INFO: task kworker/u8:7:1053 blocked for more than 143 seconds.\n        Not tainted syzkaller #0\n  \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n  task:kworker/u8:7    state:D stack:23520 pid:1053  tgid:1053  ppid:2      task_flags:0x4208060 flags:0x00080000\n  Workqueue: writeback wb_workfn (flush-btrfs-46)\n  Call Trace:\n   <TASK>\n   context_switch kernel/sched/core.c:5298 [inline]\n   __schedule+0x1553/0x5240 kernel/sched/core.c:6911\n   __schedule_loop kernel/sched/core.c:6993 [inline]\n   schedule+0x164/0x360 kernel/sched/core.c:7008\n   wait_extent_bit fs/btrfs/extent-io-tree.c:811 [inline]\n   btrfs_lock_extent_bits+0x59c/0x700 fs/btrfs/extent-io-tree.c:1914\n   btrfs_lock_extent fs/btrfs/extent-io-tree.h:152 [inline]\n   btrfs_invalidate_folio+0x43d/0xc40 fs/btrfs/inode.c:7704\n   extent_writepage fs/btrfs/extent_io.c:1852 [inline]\n   extent_write_cache_pages fs/btrfs/extent_io.c:2580 [inline]\n   btrfs_writepages+0x12ff/0x2440 fs/btrfs/extent_io.c:2713\n   do_writepages+0x32e/0x550 mm/page-writeback.c:2554\n   __writeback_single_inode+0x133/0x11a0 fs/fs-writeback.c:1750\n   writeback_sb_inodes+0x995/0x19d0 fs/fs-writeback.c:2042\n   wb_writeback+0x456/0xb70 fs/fs-writeback.c:2227\n   wb_do_writeback fs/fs-writeback.c:2374 [inline]\n   wb_workfn+0x41a/0xf60 fs/fs-writeback.c:2414\n   process_one_work kernel/workqueue.c:3276 [inline]\n   process_scheduled_works+0xb6e/0x18c0 kernel/workqueue.c:3359\n   worker_thread+0xa53/0xfc0 kernel/workqueue.c:3440\n   kthread+0x388/0x470 kernel/kthread.c:436\n   ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158\n   ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245\n   </TASK>\n  INFO: task syz.4.64:6910 blocked for more than 143 seconds.\n        Not tainted syzkaller #0\n  \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n  task:syz.4.64        state:D stack:22752 pid:6910  tgid:\n---truncated---"}],"providerMetadata":{"dateUpdated":"2026-06-24T16:30:51.941Z","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux"},"references":[{"url":"https://git.kernel.org/stable/c/73be4a08306bb84f4d5d16f62cb80e1543109ffa"},{"url":"https://git.kernel.org/stable/c/9a24f0000876b8755cf21972b41632f4d6f3dafb"},{"url":"https://git.kernel.org/stable/c/6f0f9c0a368aa1fe078109091322d3b0632d9380"},{"url":"https://git.kernel.org/stable/c/b48c980b6a7e409050bb3067165db31cc6205e3e"}],"title":"btrfs: fix deadlock between reflink and transaction commit when using flushoncommit","x_generator":{"engine":"bippy-1.2.0"}}},"cveMetadata":{"assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","assignerShortName":"Linux","cveId":"CVE-2026-53122","datePublished":"2026-06-24T16:30:51.941Z","dateReserved":"2026-06-09T07:44:35.386Z","dateUpdated":"2026-06-24T16:30:51.941Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-06-24 17:17:26","lastModifiedDate":"2026-06-24 17:17:26","problem_types":[],"metrics":[],"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"53122","Ordinal":"1","Title":"btrfs: fix deadlock between reflink and transaction commit when ","CVE":"CVE-2026-53122","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"53122","Ordinal":"1","NoteData":"In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix deadlock between reflink and transaction commit when using flushoncommit\n\nWhen using the flushoncommit mount option, we can have a deadlock between\na transaction commit and a reflink operation that copied an inline extent\nto an offset beyond the current i_size of the destination node.\n\nThe deadlock happens like this:\n\n1) Task A clones an inline extent from inode X to an offset of inode Y\n   that is beyond Y's current i_size. This means we copied the inline\n   extent's data to a folio of inode Y that is beyond its EOF, using a\n   call to copy_inline_to_page();\n\n2) Task B starts a transaction commit and calls\n   btrfs_start_delalloc_flush() to flush delalloc;\n\n3) The delalloc flushing sees the new dirty folio of inode Y and when it\n   attempts to flush it, it ends up at extent_writepage() and sees that\n   the offset of the folio is beyond the i_size of inode Y, so it attempts\n   to invalidate the folio by calling folio_invalidate(), which ends up at\n   btrfs' folio invalidate callback - btrfs_invalidate_folio(). There it\n   tries to lock the folio's range in inode Y's extent io tree, but it\n   blocks since it's currently locked by task A - during a reflink we lock\n   the inodes and the source and destination ranges after flushing all\n   delalloc and waiting for ordered extent completion - after that we\n   don't expect to have dirty folios in the ranges, the exception is if\n   we have to copy an inline extent's data (because the destination offset\n   is not zero);\n\n4) Task A then attempts to start a transaction to update the inode item,\n   and then it's blocked since the current transaction is in the\n   TRANS_STATE_COMMIT_START state. Therefore task A has to wait for the\n   current transaction to become unblocked (its state >=\n   TRANS_STATE_UNBLOCKED).\n\n   So task A is waiting for the transaction commit done by task B, and\n   the later waiting on the extent lock of inode Y that is currently\n   held by task A.\n\nSyzbot recently reported this with the following stack traces:\n\n  INFO: task kworker/u8:7:1053 blocked for more than 143 seconds.\n        Not tainted syzkaller #0\n  \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n  task:kworker/u8:7    state:D stack:23520 pid:1053  tgid:1053  ppid:2      task_flags:0x4208060 flags:0x00080000\n  Workqueue: writeback wb_workfn (flush-btrfs-46)\n  Call Trace:\n   <TASK>\n   context_switch kernel/sched/core.c:5298 [inline]\n   __schedule+0x1553/0x5240 kernel/sched/core.c:6911\n   __schedule_loop kernel/sched/core.c:6993 [inline]\n   schedule+0x164/0x360 kernel/sched/core.c:7008\n   wait_extent_bit fs/btrfs/extent-io-tree.c:811 [inline]\n   btrfs_lock_extent_bits+0x59c/0x700 fs/btrfs/extent-io-tree.c:1914\n   btrfs_lock_extent fs/btrfs/extent-io-tree.h:152 [inline]\n   btrfs_invalidate_folio+0x43d/0xc40 fs/btrfs/inode.c:7704\n   extent_writepage fs/btrfs/extent_io.c:1852 [inline]\n   extent_write_cache_pages fs/btrfs/extent_io.c:2580 [inline]\n   btrfs_writepages+0x12ff/0x2440 fs/btrfs/extent_io.c:2713\n   do_writepages+0x32e/0x550 mm/page-writeback.c:2554\n   __writeback_single_inode+0x133/0x11a0 fs/fs-writeback.c:1750\n   writeback_sb_inodes+0x995/0x19d0 fs/fs-writeback.c:2042\n   wb_writeback+0x456/0xb70 fs/fs-writeback.c:2227\n   wb_do_writeback fs/fs-writeback.c:2374 [inline]\n   wb_workfn+0x41a/0xf60 fs/fs-writeback.c:2414\n   process_one_work kernel/workqueue.c:3276 [inline]\n   process_scheduled_works+0xb6e/0x18c0 kernel/workqueue.c:3359\n   worker_thread+0xa53/0xfc0 kernel/workqueue.c:3440\n   kthread+0x388/0x470 kernel/kthread.c:436\n   ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158\n   ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245\n   </TASK>\n  INFO: task syz.4.64:6910 blocked for more than 143 seconds.\n        Not tainted syzkaller #0\n  \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n  task:syz.4.64        state:D stack:22752 pid:6910  tgid:\n---truncated---","Type":"Description","Title":"btrfs: fix deadlock between reflink and transaction commit when "}]}}}