CVE-2022-48902

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: do not WARN_ON() if we have PageError set<br /> <br /> Whenever we do any extent buffer operations we call<br /> assert_eb_page_uptodate() to complain loudly if we&amp;#39;re operating on an<br /> non-uptodate page. Our overnight tests caught this warning earlier this<br /> week<br /> <br /> WARNING: CPU: 1 PID: 553508 at fs/btrfs/extent_io.c:6849 assert_eb_page_uptodate+0x3f/0x50<br /> CPU: 1 PID: 553508 Comm: kworker/u4:13 Tainted: G W 5.17.0-rc3+ #564<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014<br /> Workqueue: btrfs-cache btrfs_work_helper<br /> RIP: 0010:assert_eb_page_uptodate+0x3f/0x50<br /> RSP: 0018:ffffa961440a7c68 EFLAGS: 00010246<br /> RAX: 0017ffffc0002112 RBX: ffffe6e74453f9c0 RCX: 0000000000001000<br /> RDX: ffffe6e74467c887 RSI: ffffe6e74453f9c0 RDI: ffff8d4c5efc2fc0<br /> RBP: 0000000000000d56 R08: ffff8d4d4a224000 R09: 0000000000000000<br /> R10: 00015817fa9d1ef0 R11: 000000000000000c R12: 00000000000007b1<br /> R13: ffff8d4c5efc2fc0 R14: 0000000001500000 R15: 0000000001cb1000<br /> FS: 0000000000000000(0000) GS:ffff8d4dbbd00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007ff31d3448d8 CR3: 0000000118be8004 CR4: 0000000000370ee0<br /> Call Trace:<br /> <br /> extent_buffer_test_bit+0x3f/0x70<br /> free_space_test_bit+0xa6/0xc0<br /> load_free_space_tree+0x1f6/0x470<br /> caching_thread+0x454/0x630<br /> ? rcu_read_lock_sched_held+0x12/0x60<br /> ? rcu_read_lock_sched_held+0x12/0x60<br /> ? rcu_read_lock_sched_held+0x12/0x60<br /> ? lock_release+0x1f0/0x2d0<br /> btrfs_work_helper+0xf2/0x3e0<br /> ? lock_release+0x1f0/0x2d0<br /> ? finish_task_switch.isra.0+0xf9/0x3a0<br /> process_one_work+0x26d/0x580<br /> ? process_one_work+0x580/0x580<br /> worker_thread+0x55/0x3b0<br /> ? process_one_work+0x580/0x580<br /> kthread+0xf0/0x120<br /> ? kthread_complete_and_exit+0x20/0x20<br /> ret_from_fork+0x1f/0x30<br /> <br /> This was partially fixed by c2e39305299f01 ("btrfs: clear extent buffer<br /> uptodate when we fail to write it"), however all that fix did was keep<br /> us from finding extent buffers after a failed writeout. It didn&amp;#39;t keep<br /> us from continuing to use a buffer that we already had found.<br /> <br /> In this case we&amp;#39;re searching the commit root to cache the block group,<br /> so we can start committing the transaction and switch the commit root<br /> and then start writing. After the switch we can look up an extent<br /> buffer that hasn&amp;#39;t been written yet and start processing that block<br /> group. Then we fail to write that block out and clear Uptodate on the<br /> page, and then we start spewing these errors.<br /> <br /> Normally we&amp;#39;re protected by the tree lock to a certain degree here. If<br /> we read a block we have that block read locked, and we block the writer<br /> from locking the block before we submit it for the write. However this<br /> isn&amp;#39;t necessarily fool proof because the read could happen before we do<br /> the submit_bio and after we locked and unlocked the extent buffer.<br /> <br /> Also in this particular case we have path-&gt;skip_locking set, so that<br /> won&amp;#39;t save us here. We&amp;#39;ll simply get a block that was valid when we<br /> read it, but became invalid while we were using it.<br /> <br /> What we really want is to catch the case where we&amp;#39;ve "read" a block but<br /> it&amp;#39;s not marked Uptodate. On read we ClearPageError(), so if we&amp;#39;re<br /> !Uptodate and !Error we know we didn&amp;#39;t do the right thing for reading<br /> the page.<br /> <br /> Fix this by checking !Uptodate &amp;&amp; !Error, this way we will not complain<br /> if our buffer gets invalidated while we&amp;#39;re using it, and we&amp;#39;ll maintain<br /> the spirit of the check which is to make sure we have a fully in-cache<br /> block while we&amp;#39;re messing with it.