CVE-2022-48902
Publication date:
22/08/2024
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&#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&#39;t keep<br />
us from continuing to use a buffer that we already had found.<br />
<br />
In this case we&#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&#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&#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&#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->skip_locking set, so that<br />
won&#39;t save us here. We&#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&#39;ve "read" a block but<br />
it&#39;s not marked Uptodate. On read we ClearPageError(), so if we&#39;re<br />
!Uptodate and !Error we know we didn&#39;t do the right thing for reading<br />
the page.<br />
<br />
Fix this by checking !Uptodate && !Error, this way we will not complain<br />
if our buffer gets invalidated while we&#39;re using it, and we&#39;ll maintain<br />
the spirit of the check which is to make sure we have a fully in-cache<br />
block while we&#39;re messing with it.
Severity CVSS v4.0: Pending analysis
Last modification:
12/09/2024
