CVE-2024-50217 Linux Btrfs UAF Patch and DoS Risk

A use-after-free bug in the Btrfs filesystem implementation has been patched in the Linux kernel under CVE-2024-50217, a high-severity flaw that can be triggered by a local attacker mounting specially crafted images and that can cause a sustained or persistent denial-of-service by corrupting kernel state during device cleanup.

Overview​

The vulnerability—tracked as CVE-2024-50217—is a use-after-free (UAF) in the Btrfs code path that handles block-device file references inside __btrfs_free_extra_devids. The issue arises when two Btrfs images that share the same filesystem ID (fsid) but have different device UUIDs (dev_uuid) are attached and mounted in a particular sequence. Under an error condition during mount (for example, an allocation failure), the code can free a bdev file reference and later attempt to fput it again, touching freed memory and producing a kernel UAF. Security scoring for the flaw puts it in the High category with a CVSS v3.1 base score of 7.8 (vector: AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H), reflecting a local attack vector that requires only low privileges but can have destructive consequences on availability and integrity.

---

Background: how the bug happens​

The sequence that triggers the UAF​

The vulnerable code path is complex but reproducible in controlled conditions. In short:

• Two disk images (image_1 and image_2) are attached to loop devices (for example, /dev/loop0 and /dev/loop1).
• The Btrfs device table is scanned (ioctl(BTRFS_IOC_SCAN_DEV), registering two btrfs_device entries that map to loop0 and loop1 respectively.
• Mounting /dev/loop0 begins; both devices have bdev_file references assigned via btrfs_get_bdev_and_sb.
• If btrfs_fill_super fails for /dev/loop0 (for example -ENOMEM), cleanup calls close routines that call fput on the device->bdev_file pointer and free the underlying structure.
• Later, mounting /dev/loop1 proceeds; the code path re-enters device cleanup logic and checks device->bdev_file. Because that pointer was freed but not cleared, the test if (device->bdev_file) and subsequent fput may operate on freed memory, causing a classical UAF.

Root cause and the upstream fix​

The immediate root cause is use of a freed pointer: the code frees a bdev file and does not reset the associated pointer to NULL, leaving a stale pointer that later is dereferenced. The accepted upstream fix (merged into the stable kernels) sets device->bdev_file = NULL after closing a btrfs_device in btrfs_close_one_device, removing the stale-pointer condition during later cleanup. Multiple vendor advisories and vulnerability databases reference this fix.

---

Affected systems and fixed versions​

The bug affects Linux kernels that include the vulnerable Btrfs code prior to the upstream fix. Vendor advisories and package trackers list affected releases and fixed package versions. Representative vendor data show:

• Debian/Ubuntu trackers list affected kernel package versions in LTS and stable releases and indicate fixes appearing in newer kernel versions (for Debian, fixed in unstable around kernel 6.11.7-1 and present in 6.12.x series).
• The upstream patch was merged into the stable kernel trees and appears in the 6.11/6.12-series stable updates (the commit references cited by vendors indicate inclusion in 6.12-rc and stable point releases).

Because distributions backport and repackage kernel fixes differently, the practical list of affected releases varies by vendor. Administrators should consult their distro's security advisory and the package management system (for example, apt, yum, zypper) for the exact kernel package that contains the fix.

---

Impact: what an attacker can do​

• Denial of Service (DoS) — The primary practical impact is availability loss. Triggering the use-after-free can crash the kernel, hang the system, or corrupt kernel memory in ways that cause persistent instability. Advisories describe the impact as a potential for “total loss of availability” of the affected component.
• Potential for escalation or integrity loss (theoretical) — While reports and vendor writeups emphasize DoS, UAFs in kernel space sometimes lead to memory corruption paths that could be escalated to more severe outcomes (arbitrary code execution) under very specific circumstances. There is no public, reliable evidence that CVE-2024-50217 has been used to escalate to full kernel RCE; vendors and vulnerability databases primarily document DoS risk. That said, UAFs in the kernel should always be treated seriously because they can, in some cases, be chained into privilege escalation.

Caveat: there are no authoritative public reports indicating active exploitation of CVE-2024-50217 in the wild as of the latest vendor advisories reviewed; however, that absence of evidence is not proof of absence. Treat claims about in-the-wild exploitation as unverifiable unless supported by incident reports or vendor telemetry.

---

Technical verification — what the sources say​

Key technical claims and their cross-checks:

• The vulnerability is a UAF in __btrfs_free_extra_devids triggered by a specific mount ordering and error path. This description is consistent across NVD, Ubuntu, Debian, OSV and other vendor trackers.
• The remedial change is to clear the pointer (device->bdev_file = NULL) after closing the device in btrfs_close_one_device. Multiple advisory summaries and the OSV entry explicitly state this is the introduced fix.
• CVSS scoring and vector (7.8 / AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) is reported consistently by NVD, Amazon Linux ALAS and other vulnerability catalogues. That vector indicates local attack requirements and potentially serious consequences for confidentiality, integrity and availability as rated by those trackers.

These cross-references to independent databases (NVD, vendor security trackers, OSV) corroborate the vulnerability description, the fix approach, and the severity ranking.

---

Mitigation and recommended actions​

A practical mitigation plan should focus on immediate risk reduction and long-term remediation.

Immediate (apply as soon as possible)​

• Install vendor-supplied kernel updates — The authoritative and effective mitigation is to apply the kernel update that contains the upstream fix. Check your distribution's security advisory and update the kernel package using the standard package manager. Confirm the kernel version includes the upstream patch (vendors list fixed package versions; for Debian/Ubuntu this was tracked in kernel 6.11.x/6.12.x updates).
• Reboot systems after kernel upgrade — Kernel patches require a reboot to take effect. Schedule reboots for systems in maintenance windows and verify new kernel is active (uname -r).

If patching is not immediately possible (workarounds)​

• Avoid mounting untrusted Btrfs images — Because the exploit requires mounting specially prepared Btrfs images, administrators can mitigate risk by not mounting any untrusted Btrfs images or attachments on production hosts until the fix is applied.
• Restrict who may create or use loop devices — The attack path commonly uses loopback devices to attach file images. Limit access to /dev/loop* and control who can create loopback attachments. Consider udev rules or filesystem permissions to constrain device access.
• Harden privileges for mount operations — Ensure only trusted administrators can mount filesystems. On multi-tenant or developer systems, reduce the set of users with CAP_SYS_ADMIN or the ability to create user namespaces that can enable mounts in containers. Some distributions restrict unprivileged user namespaces by default; verify and adjust kernel sysctls (for example, disabling unprivileged user namespaces) if applicable and acceptable for your environment.
• Use sandboxing/LSM features — Where practical, deploy Landlock, AppArmor or SELinux policies to restrict which processes can perform mount/ioctl operations or access block devices. Landlock is designed to allow unprivileged sandboxes to reduce the attack surface of user processes, though its coverage of device ioctl operations depends on ABI version and kernel support.

Detection guidance​

• Monitor kernel logs — Mount failures, device scan errors, or unexpected btrfs-related error messages in dmesg/syslog may indicate attempted triggers. Look for patterns of repeated mounts of loop devices or btrfs device-scanning ioctls originating from untrusted users.
• Audit mount operations — Audit mounts and ioctls that touch block devices. Use auditd or equivalent tooling to log privileged mount operations and loop device creation.
• Use kernel exploit detection tools — Where available, tools such as KASAN (Kernel Address Sanitizer) in test environments can help reproduce and validate crash conditions; however, KASAN is not suitable for production monitoring.

---

Operational risk analysis​

Strengths of the upstream response​

• The fix is narrow, targeted, and straightforward: clearing a stale pointer after releasing the object eliminates the UAF condition. That makes the patch easy to reason about and less likely to introduce regressions compared to larger code restructures. Upstream has merged the fix into stable kernel tree, and vendors have pushed updates.
• The vulnerability is not trivially exploitable remotely; it requires local access and a specific mount sequence or privileges to attach loopback devices—attributes that limit the initial attack surface compared with remotely exploitable kernel flaws.

Remaining risks and caveats​

• Local attack with low privileges — The CVSS vector includes PR:L (low privileges), which means non-root local users may be capable of triggering the condition if system policy allows loop device creation or mounting of images. On misconfigured or multi-tenant systems, this is a realistic concern.
• Chaining potential — While current advisories emphasize DoS, any kernel UAF is inherently dangerous because of the potential for memory corruption and the theoretical possibility of privilege escalation when combined with other bugs or attack primitives. That risk is hard to quantify and depends on kernel build options, architecture, and mitigations like KASLR, SMEP/SMAP, and compiler hardening. Treat UAFs as high-priority.
• Backporting variability — Distribution vendors sometimes backport fixes into older in-tree kernels or apply equivalent patches under different version numbers. Administrators must verify that the package they install actually contains the corrective change and not rely solely on kernel version numbers. The best practice is to review the vendor advisory or changelog entry that references the specific upstream commit or patch.

---

Practical checklist for system administrators​

• Check whether your systems use Btrfs and whether Btrfs mounts are performed on hosts by privileged or non-privileged users.
• Query your distribution's security advisory for CVE-2024-50217 and identify the fixed kernel package(s).
• Schedule package updates and reboots for affected hosts; validate the new kernel is running (uname -r).
• If a patch cannot be applied immediately:
• Restrict loop device access and mounting permissions.
• Disable unprivileged user namespaces or apply distribution-recommended hardening to reduce mount capability for untrusted accounts.
• Avoid mounting untrusted Btrfs images entirely.
• Monitor kernel logs and audit mount/ioctl activity for anomalous behavior.
• After patching, validate systems do not exhibit btrfs-related crash signatures during regression tests.

---

Developer and vendor notes​

Engineers maintaining the block-device and Btrfs code paths should take the following engineering considerations to reduce future UAF risk:

• Pointer hygiene — Following release/fput semantics, always set pointers to NULL immediately after releasing referenced kernel objects to prevent stale-pointer dereferences in later cleanup paths.
• Error-path testing — Add unit and integration tests that specifically exercise partial-failure cleanup code paths (allocation failures, I/O errors) to catch use-after-free and double-free conditions before public shipping.
• Fuzzing and sanitizers — Use KASAN, kernel fuzzing harnesses, and continuous integration tests that run errant mount and device workflows to detect memory-safety issues early.
• Clear advisory content — Vendors should include the exact upstream commit IDs or changelog excerpts in security advisories so admins can correlate package builds to upstream fixes; this mitigates uncertainty around backports. Several vendor advisories for this CVE already reference kernel commit IDs and fixed package versions, which is the correct practice.

---

Conclusion​

CVE-2024-50217 is a concrete example of how complex cleanup code paths in kernel subsystems can lead to critical memory-safety issues. The bug’s exploit path—mounting two Btrfs images with matching fsid but different dev_uuid via loop devices in a specific failure sequence—results in a use-after-free on a block-device file pointer and can be weaponized to cause sustained denial-of-service on affected systems. Vendors have merged a surgical fix (clearing the pointer after free), and distributions have been publishing patched kernel packages. Administrators should prioritize applying the vendor kernel updates, or otherwise apply strict operational mitigations (restrict mounting/loop device usage, disable unprivileged user namespaces, monitor mounts) until systems are patched. Treat kernel UAFs with high priority: even when public reports highlight DoS, the theoretical potential for more severe outcomes requires swift, careful remediation.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center