CVSS
Вероятност да бъде експлоатирана в следващите 30 дни (EPSS)
Атакува се
Време до експлоатация
Описание
Оригинално описание
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 currentl
Засегнати продукти
- Linux Linux: 05a5a7621ce66c142e081ffc24dd6ade6e912061 преди 5446d3e7676d73737f8dca816a956ede8ac24921; 05a5a7621ce66c142e081ffc24dd6ade6e912061 преди 1034251715a3474d8615232a032ed0e3451ae6ec; 05a5a7621ce66c142e081ffc24dd6ade6e912061 преди 73be4a08306bb84f4d5d16f62cb80e1543109ffa; 05a5a7621ce66c142e081ffc24dd6ade6e912061 преди 9a24f0000876b8755cf21972b41632f4d6f3dafb; 05a5a7621ce66c142e081ffc24dd6ade6e912061 преди 6f0f9c0a368aa1fe078109091322d3b0632d9380; 05a5a7621ce66c142e081ffc24dd6ade6e912061 преди b48c980b6a7e409050bb3067165db31cc6205e3e
- Linux Linux: 5.7; преди 5.7; 6.1.191 до 6.1.*; 6.6.160 до 6.6.*; 6.12.91 до 6.12.*; 6.18.33 до 6.18.*; 7.0.10 до 7.0.*; от 7.1 нататък
История
- 24 юни 2026 Публикувано
Други уязвимости в Linux Linux
Първоизточници
- https://www.cve.org/CVERecord?id=CVE-2026-53122
- https://nvd.nist.gov/vuln/detail/CVE-2026-53122
- https://git.kernel.org/stable/c/5446d3e7676d73737f8dca816a956ede8ac24921
- https://git.kernel.org/stable/c/1034251715a3474d8615232a032ed0e3451ae6ec
- https://git.kernel.org/stable/c/73be4a08306bb84f4d5d16f62cb80e1543109ffa
- https://git.kernel.org/stable/c/9a24f0000876b8755cf21972b41632f4d6f3dafb
- https://git.kernel.org/stable/c/6f0f9c0a368aa1fe078109091322d3b0632d9380
- https://git.kernel.org/stable/c/b48c980b6a7e409050bb3067165db31cc6205e3e