CVE-2023-54023

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix race between balance and cancel/pause<br /> <br /> Syzbot reported a panic that looks like this:<br /> <br /> assertion failed: fs_info-&gt;exclusive_operation == BTRFS_EXCLOP_BALANCE_PAUSED, in fs/btrfs/ioctl.c:465<br /> ------------[ cut here ]------------<br /> kernel BUG at fs/btrfs/messages.c:259!<br /> RIP: 0010:btrfs_assertfail+0x2c/0x30 fs/btrfs/messages.c:259<br /> Call Trace:<br /> <br /> btrfs_exclop_balance fs/btrfs/ioctl.c:465 [inline]<br /> btrfs_ioctl_balance fs/btrfs/ioctl.c:3564 [inline]<br /> btrfs_ioctl+0x531e/0x5b30 fs/btrfs/ioctl.c:4632<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:870 [inline]<br /> __se_sys_ioctl fs/ioctl.c:856 [inline]<br /> __x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> The reproducer is running a balance and a cancel or pause in parallel.<br /> The way balance finishes is a bit wonky, if we were paused we need to<br /> save the balance_ctl in the fs_info, but clear it otherwise and cleanup.<br /> However we rely on the return values being specific errors, or having a<br /> cancel request or no pause request. If balance completes and returns 0,<br /> but we have a pause or cancel request we won&amp;#39;t do the appropriate<br /> cleanup, and then the next time we try to start a balance we&amp;#39;ll trip<br /> this ASSERT.<br /> <br /> The error handling is just wrong here, we always want to clean up,<br /> unless we got -ECANCELLED and we set the appropriate pause flag in the<br /> exclusive op. With this patch the reproducer ran for an hour without<br /> tripping, previously it would trip in less than a few minutes.