CVE-2024-44963

What it actually does

The flaw replaces a BUG_ON() in btrfs_free_tree_block() with proper error propagation when delayed reference creation fails due to qgroup tracing errors or memory allocation failures, preventing an immediate kernel panic but requiring transaction abort to avoid space leaks.

Why it matters to the business

Systems running Linux with the btrfs file system and quotas enabled may experience unexpected crashes during disk operations under memory pressure, leading to service disruption and potential data inconsistency until patched; low urgency given absence from known exploitation lists and stable low exploit probability.

How an attack unfolds

An attacker with local access triggers btrfs tree operations under qgroups while inducing allocation failures or slot search errors; this causes the unhandled error path in btrfs_free_tree_block() to hit the BUG_ON(), resulting in a kernel panic and denial of service.

How to fix it

Upgrade the Linux kernel to a version containing commit 22d907bcd283d69d5e60497fc0d51969545c583b; for affected gnark packages update to version 0.9.2. Reboot after applying the update and verify the fix is present by checking the commit hash in the running kernel source.

How to confirm the fix worked

Confirm the running kernel includes commit 22d907bcd283d69d5e60497fc0d51969545c583b or a later equivalent; reproduce error injection scenarios with qgroups enabled and verify the transaction aborts cleanly without a BUG_ON() panic.

Typical attack path

1. Obtain local code execution on a btrfs-formatted system with quotas enabled
2. Perform file system operations that free tree blocks
3. Induce memory pressure or qgroup tracing failures via syzbot-style fuzzing or crafted workloads
4. Trigger the error return path in btrfs_free_tree_block()
5. Cause BUG_ON() to fire and panic the kernel

How to detect it

Search kernel logs and dmesg for BUG messages originating from btrfs_free_tree_block or delayed reference creation failures; correlate with qgroup activity and memory allocation error traces.

What your security team should do

• Prioritize kernel upgrade on all btrfs systems within standard patching windows
• Enable kernel panic logging and monitoring for btrfs-related oops messages
• Review and test qgroup-enabled workloads under memory constraints before deployment
• Track EPSS and KEV updates for any change in exploit likelihood