CVE-2024-50217

What it actually does

Use-after-free of the block device file pointer (device->bdev_file) in __btrfs_free_extra_devids() when btrfs encounters an error path during mount of images sharing an fsid but using distinct dev_uuids.

Why it matters to the business

Linux systems relying on btrfs may suffer kernel crashes, memory corruption, or local privilege escalation when untrusted or specially ordered multi-device images are mounted; patch urgency is moderate given low EPSS and no known KEV exploitation.

How an attack unfolds

An attacker creates two btrfs images with identical fsid but different dev_uuids, attaches them to loop devices, mounts the first image to force an -ENOMEM error that frees one bdev_file without nulling it, then mounts the second image so that btrfs_free_extra_devids dereferences the dangling pointer.

How to fix it

Apply a kernel update that sets device->bdev_file to NULL inside btrfs_close_one_device after fput; rebuild and reboot with the patched kernel.

How to confirm the fix worked

Confirm the running kernel contains the btrfs_close_one_device nulling change, then exercise repeated mount sequences of dual-image btrfs volumes while monitoring for UAF warnings or oops.

Typical attack path

1. Prepare two btrfs images sharing fsid but differing in dev_uuid
2. Attach images to loop0 and loop1
3. Issue BTRFS_IOC_SCAN_DEV and mount first image triggering btrfs_close_devices error path
4. Mount second image to reach btrfs_free_extra_devids and trigger UAF

How to detect it

Search kernel logs and dmesg for btrfs mount failures followed by use-after-free reports referencing __btrfs_free_extra_devids or bdev_file; correlate with loop device attachment events.

What your security team should do

• Deploy the btrfs UAF fix to all production kernels immediately
• Temporarily disable unprivileged loop device and btrfs mounts via sysctl or policy
• Add kernel oops and btrfs mount failure alerts to SOC monitoring