CVE-2022-49033

What it actually does

The vulnerability triggers a sleeping memory allocation (kmem_cache_alloc) from within a spinlock-held context inside btrfs_qgroup_inherit during subvolume or snapshot creation, violating kernel scheduling rules and risking BUG, deadlock, or crash.

Why it matters to the business

Linux systems using btrfs with quota groups may experience unexpected kernel panics or instability during routine volume operations, leading to downtime and potential data access disruption; the issue has been present for over two years with no observed in-the-wild exploitation.

How an attack unfolds

An attacker with local access crafts a sequence of btrfs subvolume or snapshot creation ioctls that reach btrfs_qgroup_inherit while holding the necessary locks, forcing the invalid sleep; Syzkaller-style fuzzing or targeted workload triggers the path, but no named threat actors or ransomware campaigns have been linked to this flaw.

How to fix it

Upgrade the Linux kernel to the commit 89840b12c8fad7200eb6478525c13261512c01be or any later stable release that backports the fix; ensure the running kernel contains the change that moves limit-item updates to btrfs_run_qgroups outside spinlock context.

How to confirm the fix worked

Confirm the installed kernel sources or binary contain commit 89840b12c8fad7200eb6478525c13261512c01be; attempt to reproduce the original Syzkaller reproducer and verify the BUG no longer occurs; review dmesg for absence of the sleeping-function-from-invalid-context warning during qgroup operations.

Typical attack path

1. Obtain local unprivileged or low-privileged access on a btrfs filesystem with qgroups enabled
2. Issue btrfs_ioctl_snap_create_v2 or equivalent subvolume creation calls
3. Trigger btrfs_mksubvol -> create_subvol -> btrfs_qgroup_inherit under spinlock
4. Cause kmem_cache_alloc inside update_qgroup_limit_item to sleep, hitting the BUG

How to detect it

Search kernel logs (dmesg, /var/log/kern.log) for the exact BUG string "sleeping function called from invalid context" combined with stack frames containing btrfs_qgroup_inherit, create_subvol, or update_qgroup_limit_item; correlate with recent btrfs ioctl activity or subvolume creation events.

What your security team should do

• Prioritize kernel upgrades on all multi-user or externally exposed btrfs systems within normal patch windows
• Monitor upstream stable kernel releases for additional btrfs qgroup backports
• Restrict untrusted local users from creating subvolumes or snapshots until patched
• Enable kernel lockdep and sleeping-while-atomic debugging on test systems to catch similar issues early