CVE-2026-46129

What it actually does

This is a Linux kernel memory-corruption flaw in the Btrfs filesystem error-handling path. If creation of a Btrfs space information sysfs object fails, the kernel can release the same space_info allocation twice: first through kobject_put() and the kobject release callback, then again through a direct kfree() in create_space_info(). A local authenticated attacker who can trigger the vulnerable Btrfs code path may corrupt kernel heap state, potentially causing a kernel crash or, with a reliable exploit, executing code in kernel context and escalating privileges.

Why it matters to the business

Successful exploitation can let a local user disrupt Linux systems or potentially gain full control of the affected host. The issue is not currently listed in CISA KEV, has very low EPSS, and has no known public exploit maturity in the provided data, so broad internet-scale exploitation is unlikely; however, affected Linux servers, workstations, appliances, and container hosts that use or allow Btrfs operations should still be patched because kernel privilege-escalation flaws can turn limited access into complete system compromise.

How an attack unfolds

An attacker first needs local access with low privileges on a vulnerable Linux system. They then attempt to reach the Btrfs space-info creation path, typically by performing filesystem operations involving Btrfs while manipulating conditions that cause kobject_init_and_add() or the related sysfs object creation to fail. When that failure path is hit, the kernel releases the Btrfs space_info object through the kobject cleanup callback and then incorrectly frees the same memory a second time. The resulting double free can corrupt kernel heap metadata or object reuse state. In the simplest case this crashes the kernel and causes denial of service; in a more advanced exploit, the attacker may shape heap allocations around the double free to overwrite controlled kernel data and escalate privileges to root or kernel-level execution.

How to fix it

Upgrade to a Linux kernel build that includes the Btrfs fix for the create_space_info() double-free error path. Because exact fixed package versions were not provided, use the kernel version supplied by the relevant Linux distribution, appliance vendor, cloud image provider, or upstream stable kernel branch that references this fix. After updating, reboot into the patched kernel and remove or decommission older vulnerable kernels where operationally feasible. As temporary mitigations, restrict local shell access, limit who can mount or manage Btrfs filesystems, disable unneeded Btrfs usage where possible, and enforce standard kernel hardening controls such as unprivileged user namespace restrictions, module loading restrictions, SELinux/AppArmor policy, and least-privilege sudo rules. Mitigations should not be treated as a substitute for patching because the vulnerable code is in kernel memory management behavior.

How to confirm the fix worked

Confirm the running kernel version with uname -a and verify it matches a vendor kernel release that includes the Btrfs double-free fix. Check package metadata with the platform’s package manager, such as rpm -q --changelog kernel, dpkg -l linux-image-*, apt changelog, yum/dnf updateinfo, or vendor advisories, for references to the Btrfs create_space_info() or kobject_init_and_add() double-free fix. Ensure the system has been rebooted into the patched kernel rather than only installing the update. Validate exposure by checking whether Btrfs is in use with findmnt -t btrfs, mount | grep btrfs, lsmod | grep btrfs, and filesystem inventory tooling. If Btrfs is not loaded and no Btrfs filesystems are mounted, practical exposure is reduced but patching is still recommended for systems carrying the vulnerable kernel.

Typical attack path

1. Obtain local low-privileged access to a vulnerable Linux system.
2. Identify that the system is running an affected kernel with Btrfs support enabled and accessible.
3. Trigger Btrfs filesystem activity that reaches create_space_info() and btrfs_sysfs_add_space_info_type().
4. Induce or wait for a failure in kobject_init_and_add() or the associated sysfs object creation path.
5. Cause the kernel to execute the vulnerable error path where space_info is freed twice.
6. Use the resulting kernel heap corruption to crash the system or attempt privilege escalation.

How to detect it

To determine whether exploitation was already attempted, review kernel and system logs for crashes or memory-corruption reports involving Btrfs space information creation, kobject handling, sysfs object creation, kfree(), slab allocator errors, double-free warnings, kernel oopses, panics, or unexpected reboots. Relevant sources include journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, persistent systemd journals, crash dumps under /var/crash, kdump/vmcore artifacts, EDR kernel telemetry, and hypervisor or cloud provider reboot/crash events. Correlate suspicious kernel events with local user activity, mount commands, filesystem creation, Btrfs subvolume operations, loop device usage, namespace/container activity, sudo logs, auditd records, and any subsequent privilege escalation indicators such as new root-owned files, setuid binaries, unexpected kernel modules, or new privileged users. There are no known public exploit-specific network indicators in the provided data because this is a local kernel flaw, so detection should focus on host telemetry and post-exploitation behavior.

• double free
• Double free
• kfree
• kobject_init_and_add
• kobject_put
• space_info_release
• create_space_info
• btrfs_sysfs_add_space_info_type
• BTRFS
• btrfs
• kernel BUG
• kernel panic
• Oops
• slab:
• SLUB:
• general protection fault
• use-after-free
• BUG: KASAN
• /var/crash
• /proc/vmcore
• findmnt -t btrfs
• mount -t btrfs

What your security team should do

• Prioritize patching Linux systems that use Btrfs, allow local interactive access, run multi-user workloads, or host containers/CI workloads where local privilege escalation would be high impact.
• Track distribution-specific kernel advisories and deploy the first vendor-supported kernel release containing the Btrfs double-free fix; reboot systems after installation.
• Inventory Btrfs usage across servers, workstations, appliances, and base images to identify systems with the highest exposure.
• Temporarily restrict untrusted local users from mounting, creating, or administering Btrfs filesystems until patched.
• Review recent kernel crash, oops, and panic logs for Btrfs, kobject, kfree, slab, or double-free messages that could indicate attempted triggering.
• Because EPSS is very low, the CVE is not KEV-listed, and no exploit maturity is reported, schedule remediation based on local-access risk rather than emergency internet-exposed risk.
• Preserve forensic data from any affected host showing unexplained Btrfs-related kernel crashes, especially if followed by suspicious privilege changes or root-level activity.