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:
kobject_init_and_add()fails and the code callskobject_put(&space_info->kobj).- That
kobject_put()fires the release callback,space_info_release(), which runskfree(space_info). The memory is now gone. - Control returns to
create_space_info(), it sees the error, jumps to itsout_freelabel, and callskfree(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
- NVD — CVE-2026-46129