CVE-2024-35956

What it actually does

In btrfs with qgroups or squotas enabled, error paths in subvolume create, snapshot, and delete operations incorrectly convert PREALLOC reservations to PERTRANS without recording the root in the transaction, causing the reservation to leak until unmount and triggering a warning under CONFIG_BTRFS_DEBUG.

Why it matters to the business

Systems running btrfs with quotas enabled may experience gradual metadata reservation leaks during subvolume operations that hit errors, leading to warnings on unmount and potential long-term resource accounting issues on high-churn filesystems.

How an attack unfolds

An attacker would need local access to trigger btrfs subvolume create, snapshot, or delete operations that encounter errors before record_root_in_trans succeeds; the bug is not remotely exploitable and does not grant code execution or privilege escalation.

How to fix it

Upgrade the Linux kernel to the fixed commit 945559be6e282a812dc48f7bcd5adc60901ea4a0 or later stable release containing the corrected qgroup reservation lifecycle handling for the three subvolume operations.

How to confirm the fix worked

Confirm the running kernel contains commit 945559be6e282a812dc48f7bcd5adc60901ea4a0; reproduce generic/269 with squotas at mkfs time and verify it completes without warnings or leaks over many iterations.

Typical attack path

1. Obtain local unprivileged access on a btrfs filesystem with quotas enabled
2. Trigger subvolume create, snapshot, or delete operations that fail in specific error paths
3. Cause repeated leaks of PERTRANS reservations that are not freed at transaction end

How to detect it

Review kernel logs at unmount for CONFIG_BTRFS_DEBUG warnings about leaked reservations; inspect btrfs qgroup accounting and transaction commit paths for unexpected PERTRANS entries that persist across operations.

What your security team should do

• Prioritize kernel upgrades on any btrfs deployments using qgroups or squotas
• Monitor unmount logs for btrfs reservation warnings on debug kernels
• Test subvolume-heavy workloads after patching to confirm leak is resolved