CVE-2024-49867 — btrfs: wait for fixup workers before stopping cleaner kthread during umount

Affected: Linux

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

btrfs: wait for fixup workers before stopping cleaner kthread during umount

During unmount, at close_ctree(), we have the following steps in this order:

1) Park the cleaner kthread - this doesn't destroy the kthread, it basically halts its execution (wake ups against it work but do nothing);

2) We stop the cleaner kthread - this results in freeing the respective struct task_struct;

3) We call btrfs_stop_all_workers() which waits for any jobs running in all the work queues and then free the work queues.

Syzbot reported a case where a fixup worker resulted in a crash when doing a delayed iput on its inode while attempting to wake up the cleaner at btrfs_add_delayed_iput(), because the task_struct of the cleaner kthread was already freed. This can happen during unmount because we don't wait for any fixup workers still running before we call kthread_stop() against the cleaner kthread, which stops and free all its resources.

Fix this by waiting for any fixup workers at close_ctree() before we call kthread_stop() against the cleaner and run pending delayed iputs.

The stack traces reported by syzbot were the following:

BUG: KASAN: slab-use-after-free in __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52

CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engi…

Most recent entries from all

CVE-2024-49867 — btrfs: wait for fixup workers before stopping cleaner kthread during umount