{"id":76055,"date":"2026-01-31T15:46:06","date_gmt":"2026-01-31T12:16:06","guid":{"rendered":"https:\/\/afaghhosting.net\/blog\/cve-2026-23036-btrfs-release-path-before-iget_failed-in-btrfs_read_locked_inode\/"},"modified":"2026-01-31T15:46:06","modified_gmt":"2026-01-31T12:16:06","slug":"cve-2026-23036-btrfs-release-path-before-iget_failed-in-btrfs_read_locked_inode","status":"publish","type":"post","link":"https:\/\/afaghhosting.net\/blog\/cve-2026-23036-btrfs-release-path-before-iget_failed-in-btrfs_read_locked_inode\/","title":{"rendered":"CVE-2026-23036 &#8211; btrfs: release path before iget_failed() in btrfs_read_locked_inode()"},"content":{"rendered":"<p>CVE ID : CVE-2026-23036<\/p>\n<p>Published :  Jan. 31, 2026, 12:16 p.m. | 57\u00a0minutes ago<\/p>\n<p>Description : In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>btrfs: release path before iget_failed() in btrfs_read_locked_inode()<\/p>\n<p>In btrfs_read_locked_inode() if we fail to lookup the inode, we jump to<br \/>\nthe &#8216;out&#8217; label with a path that has a read locked leaf and then we call<br \/>\niget_failed(). This can result in a ABBA deadlock, since iget_failed()<br \/>\ntriggers inode eviction and that causes the release of the delayed inode,<br \/>\nwhich must lock the delayed inode&#8217;s mutex, and a task updating a delayed<br \/>\ninode starts by taking the node&#8217;s mutex and then modifying the inode&#8217;s<br \/>\nsubvolume btree.<\/p>\n<p>Syzbot reported the following lockdep splat for this:<\/p>\n<p>   ======================================================<br \/>\n   WARNING: possible circular locking dependency detected<br \/>\n   syzkaller #0 Not tainted<br \/>\n   &#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;<br \/>\n   btrfs-cleaner\/8725 is trying to acquire lock:<br \/>\n   ffff0000d6826a48 (&amp;delayed_node-&gt;mutex){+.+.}-{4:4}, at: __btrfs_release_delayed_node+0xa0\/0x9b0 fs\/btrfs\/delayed-inode.c:290<\/p>\n<p>   but task is already holding lock:<br \/>\n   ffff0000dbeba878 (btrfs-tree-00){++++}-{4:4}, at: btrfs_tree_read_lock_nested+0x44\/0x2ec fs\/btrfs\/locking.c:145<\/p>\n<p>   which lock already depends on the new lock.<\/p>\n<p>   the existing dependency chain (in reverse order) is:<\/p>\n<p>   -&gt; #1 (btrfs-tree-00){++++}-{4:4}:<br \/>\n          __lock_release kernel\/locking\/lockdep.c:5574 [inline]\n          lock_release+0x198\/0x39c kernel\/locking\/lockdep.c:5889<br \/>\n          up_read+0x24\/0x3c kernel\/locking\/rwsem.c:1632<br \/>\n          btrfs_tree_read_unlock+0xdc\/0x298 fs\/btrfs\/locking.c:169<br \/>\n          btrfs_tree_unlock_rw fs\/btrfs\/locking.h:218 [inline]\n          btrfs_search_slot+0xa6c\/0x223c fs\/btrfs\/ctree.c:2133<br \/>\n          btrfs_lookup_inode+0xd8\/0x38c fs\/btrfs\/inode-item.c:395<br \/>\n          __btrfs_update_delayed_inode+0x124\/0xed0 fs\/btrfs\/delayed-inode.c:1032<br \/>\n          btrfs_update_delayed_inode fs\/btrfs\/delayed-inode.c:1118 [inline]\n          __btrfs_commit_inode_delayed_items+0x15f8\/0x1748 fs\/btrfs\/delayed-inode.c:1141<br \/>\n          __btrfs_run_delayed_items+0x1ac\/0x514 fs\/btrfs\/delayed-inode.c:1176<br \/>\n          btrfs_run_delayed_items_nr+0x28\/0x38 fs\/btrfs\/delayed-inode.c:1219<br \/>\n          flush_space+0x26c\/0xb68 fs\/btrfs\/space-info.c:828<br \/>\n          do_async_reclaim_metadata_space+0x110\/0x364 fs\/btrfs\/space-info.c:1158<br \/>\n          btrfs_async_reclaim_metadata_space+0x90\/0xd8 fs\/btrfs\/space-info.c:1226<br \/>\n          process_one_work+0x7e8\/0x155c kernel\/workqueue.c:3263<br \/>\n          process_scheduled_works kernel\/workqueue.c:3346 [inline]\n          worker_thread+0x958\/0xed8 kernel\/workqueue.c:3427<br \/>\n          kthread+0x5fc\/0x75c kernel\/kthread.c:463<br \/>\n          ret_from_fork+0x10\/0x20 arch\/arm64\/kernel\/entry.S:844<\/p>\n<p>   -&gt; #0 (&amp;delayed_node-&gt;mutex){+.+.}-{4:4}:<br \/>\n          check_prev_add kernel\/locking\/lockdep.c:3165 [inline]\n          check_prevs_add kernel\/locking\/lockdep.c:3284 [inline]\n          validate_chain kernel\/locking\/lockdep.c:3908 [inline]\n          __lock_acquire+0x1774\/0x30a4 kernel\/locking\/lockdep.c:5237<br \/>\n          lock_acquire+0x14c\/0x2e0 kernel\/locking\/lockdep.c:5868<br \/>\n          __mutex_lock_common+0x1d0\/0x2678 kernel\/locking\/mutex.c:598<br \/>\n          __mutex_lock kernel\/locking\/mutex.c:760 [inline]\n          mutex_lock_nested+0x2c\/0x38 kernel\/locking\/mutex.c:812<br \/>\n          __btrfs_release_delayed_node+0xa0\/0x9b0 fs\/btrfs\/delayed-inode.c:290<br \/>\n          btrfs_release_delayed_node fs\/btrfs\/delayed-inode.c:315 [inline]\n          btrfs_remove_delayed_node+0x68\/0x84 fs\/btrfs\/delayed-inode.c:1326<br \/>\n          btrfs_evict_inode+0x578\/0xe28 fs\/btrfs\/inode.c:5587<br \/>\n          evict+0x414\/0x928 fs\/inode.c:810<br \/>\n          iput_final fs\/inode.c:1914 [inline]\n          iput+0x95c\/0xad4 fs\/inode.c:1966<br \/>\n          iget_failed+0xec\/0x134 fs\/bad_inode.c:248<br \/>\n          btrfs_read_locked_inode+0xe1c\/0x1234 fs\/btrfs\/inode.c:4101<br \/>\n          btrfs_iget+0x1b0\/0x264 fs\/btrfs\/inode.c:5837<br \/>\n          btrfs_run_defrag_inode fs\/btrfs\/defrag.c:237 [inline]\n          btrfs_run_defrag_inodes+0x520\/0xdc4 fs\/btrf<br \/>\n&#8212;truncated&#8212;<\/p>\n<p>Severity: 0.0 | NA<\/p>\n<p>Visit the link for more details, such as CVSS details, affected products, timeline, and more&#8230;\u00a0<\/p>\n","protected":false},"excerpt":{"rendered":"<p>CVE ID : CVE-2026-23036 Published : Jan. 31, 2026, 12:16 p.m. | 57\u00a0minutes ago Description : In the Linux kernel, the following vulnerability has been resolved: btrfs: release path before iget_failed() in btrfs_read_locked_inode() In btrfs_read_locked_inode() if we fail to lookup the inode, we jump to the &#8216;out&#8217; label with a path that has a read &hellip;<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-76055","post","type-post","status-publish","format-standard","hentry","category-vulnerability"],"_links":{"self":[{"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/posts\/76055","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/comments?post=76055"}],"version-history":[{"count":0,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/posts\/76055\/revisions"}],"wp:attachment":[{"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/media?parent=76055"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/categories?post=76055"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/tags?post=76055"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}