# CVE-2026-46129: Btrfs double-free triggered by a sysfs kobject registration failure

- **Published on:** 2026-05-28
- **Category:** Security
- **Original page:** https://linuxgratis.com/en/articles/cve-2026-46129-btrfs-double-free-create-space-info-kernel-linux

A double free in the error path of Btrfs create_space_info() can corrupt kernel memory. Here is who it affects, how serious it is, and how to patch it.

---

CVE-2026-46129 is a memory corruption flaw in the Btrfs filesystem of the Linux kernel. It landed on the NVD on 28 May 2026 with a CVSS 3.1 score of 7.8 (high) and the vector `AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H`. The short version: it needs local access, but if it fires, the impact on confidentiality, integrity and availability is high.

## What actually goes wrong

The bug lives in `create_space_info()`, the function that builds Btrfs space-info structures while the filesystem initialises. That function calls `btrfs_sysfs_add_space_info_type()`, which in turn uses `kobject_init_and_add()` to register a kobject in sysfs.

When `kobject_init_and_add()` fails, the same `space_info` structure gets freed twice. The chain looks like this:

1. `kobject_init_and_add()` fails and the code calls `kobject_put(&space_info->kobj)`.
2. That `kobject_put()` fires the release callback, `space_info_release()`, which runs `kfree(space_info)`. The memory is now gone.
3. Control returns to `create_space_info()`, it sees the error, jumps to its `out_free` label, and calls `kfree(space_info)` again on the already-freed pointer.

Two cleanup paths each believe they own the same object. One hands it back to the allocator, the other frees it a second time. In the kernel, a double free like this can turn into heap corruption, use-after-free conditions, a kernel panic, or in the worst case arbitrary code execution.

## Who is affected

Any system running a Linux kernel that mounts or has Btrfs available. In practice that covers storage servers, NAS boxes, backup appliances, Linux VMs, container platforms and development environments where Btrfs is the filesystem. Distributions such as Fedora and openSUSE ship it by default, so the reach is not marginal.

The window to trigger the bug is narrow. You have to force `kobject_init_and_add()` to fail during space-info creation, which depends on allocator behaviour, kernel configuration and active hardening. That keeps the attack surface local, and as of publication there is no public exploit and no known in-the-wild exploitation.

## How serious it is

The 7.8 puts this above many Btrfs bugs because the vector flags high impact across all three dimensions. Read it alongside the context, though: it requires local privileges (`PR:L`) and there is no remote vector. This is not a drop-everything panic, but it is worth patching promptly on any multi-user host or anything running third-party workloads.

## Mitigation and patch

The fix corrects the memory ownership contract. Early failure paths keep the direct `kfree(space_info)`, but once `btrfs_sysfs_add_space_info_type()` has already called `kobject_put()`, the kobject release callback is left to handle cleanup. That way nobody frees the structure twice.

The patch propagated to several kernel.org stable branches in late May 2026. The right move is to update through your distribution or appliance vendor channel and confirm the backport in their security advisory rather than trusting the upstream version number alone, since vendors renumber their kernels. After installing the patched kernel you need to reboot for the change to take effect. If you cannot patch immediately, restricting local access for untrusted users reduces your exposure in the meantime.

## Source

- Windows Forum — [CVE-2026-46129 Btrfs double-free fix: Linux kernel patch needed](https://windowsforum.com/threads/cve-2026-46129-btrfs-double-free-fix-linux-kernel-patch-needed.420748/)
- NVD — [CVE-2026-46129](https://nvd.nist.gov/vuln/detail/CVE-2026-46129)