CVE-2026-46164

What it actually does

This is a Linux kernel memory-management flaw in the Btrfs filesystem sysfs setup path. If kobject_init_and_add() fails while creating a Btrfs space-info subgroup, the error path can release the same sub_group allocation twice: first through kobject_put() and the kobject release callback, then again when control returns to create_space_info_sub_group(). A double free in kernel memory can lead to memory corruption and, depending on heap layout and exploitability, may cause kernel crash, denial of service, information disclosure, or potential privilege escalation. The CVSS vector indicates local attack surface, high attack complexity, no privileges required, and required user interaction, so practical exploitation is likely constrained and environment-dependent.

Why it matters to the business

Successful exploitation could destabilize Linux systems using Btrfs, potentially causing crashes, service outages, or—in a worst case—local compromise of the host. Because this is in kernel code, any exploitable impact is high severity even though exploitation appears difficult, local, and not currently known to be used in the wild. Organizations that rely on Btrfs for servers, appliances, containers, desktops, or storage workloads should treat this as a kernel maintenance priority, especially where untrusted users can influence filesystem activity or mount/use Btrfs volumes.

How an attack unfolds

An attacker would need a way to trigger the vulnerable Btrfs code path on a local Linux system. The vulnerable condition occurs during creation of Btrfs sysfs space-info subgroup state when kobject_init_and_add() fails. Exploitation would require shaping system state so that the kobject initialization/add operation fails and the error-handling path is reached. The kernel then releases the subgroup through kobject_put(), whose release callback frees the object, and subsequently attempts to free the same object again. A reliable exploit would likely require careful manipulation of kernel heap state after the first free so that the second free corrupts useful allocator metadata or object state. In less controlled cases, exploitation is more likely to result in a kernel oops, panic, or filesystem-related instability than reliable code execution. No public exploit maturity or known in-the-wild exploitation is indicated by the provided data.

How to fix it

Update the Linux kernel to a vendor release that includes the Btrfs fix for the create_space_info_sub_group() double-free error path. Because fixed versions were not provided in the input, use distribution-specific security advisories and kernel changelogs to identify the corrected package for each platform. Where immediate patching is not possible, reduce exposure by avoiding Btrfs on affected systems, preventing untrusted users from mounting or manipulating Btrfs filesystems, disabling unneeded Btrfs kernel module loading where feasible, and limiting local interactive access. Kernel live patching may be used if provided by the operating system vendor and if the live patch explicitly covers this flaw.

How to confirm the fix worked

Confirm remediation by verifying the running kernel build includes the upstream or vendor patch for the Btrfs create_space_info_sub_group() error path and that the installed kernel package matches the vendor-fixed advisory version. Reboot into the fixed kernel after installation; merely installing a kernel package is not sufficient if the system is still running an older kernel. Validate exposure by checking whether Btrfs is supported or loaded and whether any Btrfs filesystems are mounted. Useful checks include reviewing `uname -a`, distribution package versions, `/proc/filesystems`, `lsmod` output for `btrfs`, and active mounts for filesystem type `btrfs`. In test environments, filesystem regression tests should verify Btrfs sysfs space-info handling does not crash under allocation or kobject failure injection.

Typical attack path

1. Gain local ability to interact with a Linux system that has Btrfs support and is running an affected kernel.
2. Trigger Btrfs operations that create space-info sysfs subgroup structures.
3. Induce or race conditions so kobject_init_and_add() fails during subgroup creation.
4. Cause the error path to call kobject_put(), freeing the subgroup through the kobject release callback.
5. Allow execution to return to create_space_info_sub_group(), where the same subgroup is freed again.
6. Attempt to use resulting kernel heap corruption for denial of service or, with sufficient heap control, possible privilege escalation.

How to detect it

There are no definitive, vulnerability-specific indicators of exploitation from the provided information, and successful kernel memory corruption may leave limited artifacts. Look for local activity followed by kernel oopses, panics, slab allocator corruption, Btrfs sysfs errors, kobject errors, or unexpected reboots. Review kernel logs from `dmesg`, journald, `/var/log/kern.log`, `/var/log/messages`, crash dumps, kdump/vmcore artifacts, and EDR telemetry around the time of instability. Focus on hosts with Btrfs loaded or mounted. Investigate suspicious local users or processes that performed Btrfs mount, filesystem creation, quota, balance, or device operations shortly before kernel faults. If crash dumps are available, inspect stack traces for Btrfs functions such as create_space_info_sub_group(), btrfs_sysfs_add_space_info_type(), kobject_init_and_add(), kobject_put(), and space_info_release().

• create_space_info_sub_group
• btrfs_sysfs_add_space_info_type
• kobject_init_and_add
• kobject_put
• space_info_release
• double free
• kernel BUG
• Oops
• general protection fault
• slab corruption
• use-after-free
• BUG: KASAN
• btrfs
• BTRFS
• /proc/filesystems
• /sys/fs/btrfs
• /var/log/kern.log
• /var/log/messages
• vmcore

What your security team should do

• Prioritize patching Linux systems that use Btrfs or allow local users to create, mount, or manipulate Btrfs filesystems.
• Track operating-system vendor advisories for the exact fixed kernel package, since no fixed version was provided in the vulnerability metadata.
• Reboot systems after applying the fixed kernel and verify the running kernel, not just the installed package, is remediated.
• Where patching is delayed, restrict local shell access, container privileges, and mount capabilities that could enable Btrfs interaction by untrusted users.
• Disable or prevent loading of the Btrfs module on systems that do not require Btrfs, if compatible with operational requirements.
• Monitor for kernel crashes, Btrfs warnings, and sysfs/kobject errors that could indicate attempts to trigger the vulnerable path.
• Because this is not listed in KEV, has low EPSS, and has no indicated exploit maturity, handle through risk-based kernel patch management rather than emergency internet-facing incident response unless local threat exposure is high.