CVE-2024-42103

In the Linux kernel, the following vulnerability has been resolved:

btrfs: fix adding block group to a reclaim list and the unused list during reclaim

There is a potential parallel list adding for retrying in btrfsreclaimbgs_work and adding to the unused list. Since the block group is removed from the reclaim list and it is on a relocation work, it can be added into the unused list in parallel. When that happens, adding it to the reclaim list will corrupt the list head and trigger list corruption like below.

Fix it by taking fsinfo->unusedbgs_lock.

[177.504][T2585409] BTRFS error (device nullb1): error relocating ch= unk 2415919104 [177.514][T2585409] listdel corruption. next->prev should be ff1100= 0344b119c0, but was ff11000377e87c70. (next=3Dff110002390cd9c0) [177.529][T2585409] ------------[ cut here ]------------ [177.537][T2585409] kernel BUG at lib/listdebug.c:65! [177.545][T2585409] Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI [177.555][T2585409] CPU: 9 PID: 2585409 Comm: kworker/u128:2 Tainted: G W 6.10.0-rc5-kts #1 [177.568][T2585409] Hardware name: Supermicro SYS-520P-WTR/X12SPW-TF, BIOS 1.2 02/14/2022 [177.579][T2585409] Workqueue: eventsunbound btrfsreclaimbgswork[btrfs] [177.589][T2585409] RIP: 0010:_listdelentryvalidorreport.cold+0x70/0x72 [177.624][T2585409] RSP: 0018:ff11000377e87a70 EFLAGS: 00010286 [177.633][T2585409] RAX: 000000000000006d RBX: ff11000344b119c0 RCX:0000000000000000 [177.644][T2585409] RDX: 000000000000006d RSI: 0000000000000008 RDI:ffe21c006efd0f40 [177.655][T2585409] RBP: ff110002e0509f78 R08: 0000000000000001 R09:ffe21c006efd0f08 [177.665][T2585409] R10: ff11000377e87847 R11: 0000000000000000 R12:ff110002390cd9c0 [177.676][T2585409] R13: ff11000344b119c0 R14: ff110002e0508000 R15:dffffc0000000000 [177.687][T2585409] FS: 0000000000000000(0000) GS:ff11000fec880000(0000) knlGS:0000000000000000 [177.700][T2585409] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [177.709][T2585409] CR2: 00007f06bc7b1978 CR3: 0000001021e86005 CR4:0000000000771ef0 [177.720][T2585409] DR0: 0000000000000000 DR1: 0000000000000000 DR2:0000000000000000 [177.731][T2585409] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:0000000000000400 [177.742][T2585409] PKRU: 55555554 [177.748][T2585409] Call Trace: [177.753][T2585409] <TASK> [177.759][T2585409] ? _diebody.cold+0x19/0x27 [177.766][T2585409] ? die+0x2e/0x50 [177.772][T2585409] ? dotrap+0x1ea/0x2d0 [177.779][T2585409] ? _listdelentryvalidorreport.cold+0x70/0x72 [177.788][T2585409] ? doerrortrap+0xa3/0x160 [177.795][T2585409] ? _listdelentryvalidorreport.cold+0x70/0x72 [177.805][T2585409] ? handleinvalidop+0x2c/0x40 [177.812][T2585409] ? _listdelentryvalidorreport.cold+0x70/0x72 [177.820][T2585409] ? excinvalidop+0x2d/0x40 [177.827][T2585409] ? asmexcinvalidop+0x1a/0x20 [177.834][T2585409] ? _listdelentryvalidorreport.cold+0x70/0x72 [177.843][T2585409] btrfsdeleteunused_bgs+0x3d9/0x14c0 [btrfs]

There is a similar retrylist code in btrfsdeleteunusedbgs(), but it is safe, AFAICS. Since the block group was in the unused list, the used bytes should be 0 when it was added to the unused list. Then, it checks blockgroup->{used,reserved,pinned} are still 0 under the blockgroup->lock. So, they should be still eligible for the unused list, not the reclaim list.

The reason it is safe there it's because because we're holding spaceinfo->groupssem in write mode.

That means no other task can allocate from the block group, so while we are at deletedunusedbgs() it's not possible for other tasks to allocate and deallocate extents from the block group, so it can't be added to the unused list or the reclaim list by anyone else.

The bug can be reproduced by btrfs/166 after a few rounds. In practice this can be hit when relocation cannot find more chunk space and ends with ENOSPC.