CVE-2024-26644: btrfs: don't abort filesystem when attempting to snapshot deleted subvolume

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

btrfs: don't abort filesystem when attempting to snapshot deleted subvolume

If the source file descriptor to the snapshot ioctl refers to a deleted subvolume, we get the following abort:

BTRFS: Transaction aborted (error -2) WARNING: CPU: 0 PID: 833 at fs/btrfs/transaction.c:1875 creatependingsnapshot+0x1040/0x1190 [btrfs] Modules linked in: pataacpi btrfs atapiix libata scsimod virtionet blake2bgeneric xor netfailover virtiorng failover scsicommon rngcore raid6pq libcrc32c CPU: 0 PID: 833 Comm: tsnapshotdele Not tainted 6.7.0-rc6 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014 RIP: 0010:creatependingsnapshot+0x1040/0x1190 [btrfs] RSP: 0018:ffffa09c01337af8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff9982053e7c78 RCX: 0000000000000027 RDX: ffff99827dc20848 RSI: 0000000000000001 RDI: ffff99827dc20840 RBP: ffffa09c01337c00 R08: 0000000000000000 R09: ffffa09c01337998 R10: 0000000000000003 R11: ffffffffb96da248 R12: fffffffffffffffe R13: ffff99820535bb28 R14: ffff99820b7bd000 R15: ffff99820381ea80 FS: 00007fe20aadabc0(0000) GS:ffff99827dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000559a120b502f CR3: 00000000055b6000 CR4: 00000000000006f0 Call Trace: <TASK> ? creatependingsnapshot+0x1040/0x1190 [btrfs] ? warn+0x81/0x130 ? creatependingsnapshot+0x1040/0x1190 [btrfs] ? reportbug+0x171/0x1a0 ? handlebug+0x3a/0x70 ? excinvalidop+0x17/0x70 ? asmexcinvalidop+0x1a/0x20 ? creatependingsnapshot+0x1040/0x1190 [btrfs] ? creatependingsnapshot+0x1040/0x1190 [btrfs] creatependingsnapshots+0x92/0xc0 [btrfs] btrfscommittransaction+0x66b/0xf40 [btrfs] btrfsmksubvol+0x301/0x4d0 [btrfs] btrfsmksnapshot+0x80/0xb0 [btrfs] btrfsioctlsnapcreate+0x1c2/0x1d0 [btrfs] btrfsioctlsnapcreatev2+0xc4/0x150 [btrfs] btrfsioctl+0x8a6/0x2650 [btrfs] ? kmemcachefree+0x22/0x340 ? dosysopenat2+0x97/0xe0 x64sysioctl+0x97/0xd0 dosyscall64+0x46/0xf0 entrySYSCALL64afterhwframe+0x6e/0x76 RIP: 0033:0x7fe20abe83af RSP: 002b:00007ffe6eff1360 EFLAGS: 00000246 ORIGRAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fe20abe83af RDX: 00007ffe6eff23c0 RSI: 0000000050009417 RDI: 0000000000000003 RBP: 0000000000000003 R08: 0000000000000000 R09: 00007fe20ad16cd0 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffe6eff13c0 R14: 00007fe20ad45000 R15: 0000559a120b6d58 </TASK> ---[ end trace 0000000000000000 ]--- BTRFS: error (device vdc: state A) in creatependingsnapshot:1875: errno=-2 No such entry BTRFS info (device vdc: state EA): forced readonly BTRFS warning (device vdc: state EA): Skipping commit of aborted transaction. BTRFS: error (device vdc: state EA) in cleanuptransaction:2055: errno=-2 No such entry

This happens because creatependingsnapshot() initializes the new root item as a copy of the source root item. This includes the refs field, which is 0 for a deleted subvolume. The call to btrfsinsertroot() therefore inserts a root with refs == 0. btrfsgetnewfsroot() then finds the root and returns -ENOENT if refs == 0, which causes creatependingsnapshot() to abort.

Fix it by checking the source root's refs before attempting the snapshot, but after locking subvolsem to avoid racing with deletion.