CVE-2024-26727

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: do not ASSERT() if the newly created subvolume already got read<br /> <br /> [BUG]<br /> There is a syzbot crash, triggered by the ASSERT() during subvolume<br /> creation:<br /> <br /> assertion failed: !anon_dev, in fs/btrfs/disk-io.c:1319<br /> ------------[ cut here ]------------<br /> kernel BUG at fs/btrfs/disk-io.c:1319!<br /> invalid opcode: 0000 [#1] PREEMPT SMP KASAN<br /> RIP: 0010:btrfs_get_root_ref.part.0+0x9aa/0xa60<br /> <br /> btrfs_get_new_fs_root+0xd3/0xf0<br /> create_subvol+0xd02/0x1650<br /> btrfs_mksubvol+0xe95/0x12b0<br /> __btrfs_ioctl_snap_create+0x2f9/0x4f0<br /> btrfs_ioctl_snap_create+0x16b/0x200<br /> btrfs_ioctl+0x35f0/0x5cf0<br /> __x64_sys_ioctl+0x19d/0x210<br /> do_syscall_64+0x3f/0xe0<br /> entry_SYSCALL_64_after_hwframe+0x63/0x6b<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> [CAUSE]<br /> During create_subvol(), after inserting root item for the newly created<br /> subvolume, we would trigger btrfs_get_new_fs_root() to get the<br /> btrfs_root of that subvolume.<br /> <br /> The idea here is, we have preallocated an anonymous device number for<br /> the subvolume, thus we can assign it to the new subvolume.<br /> <br /> But there is really nothing preventing things like backref walk to read<br /> the new subvolume.<br /> If that happens before we call btrfs_get_new_fs_root(), the subvolume<br /> would be read out, with a new anonymous device number assigned already.<br /> <br /> In that case, we would trigger ASSERT(), as we really expect no one to<br /> read out that subvolume (which is not yet accessible from the fs).<br /> But things like backref walk is still possible to trigger the read on<br /> the subvolume.<br /> <br /> Thus our assumption on the ASSERT() is not correct in the first place.<br /> <br /> [FIX]<br /> Fix it by removing the ASSERT(), and just free the @anon_dev, reset it<br /> to 0, and continue.<br /> <br /> If the subvolume tree is read out by something else, it should have<br /> already get a new anon_dev assigned thus we only need to free the<br /> preallocated one.