CVE-2026-31434

What it actually does

This is a Linux kernel Btrfs memory leak in the sysfs handling for Btrfs space_info sub-groups. During Btrfs filesystem setup, kobject_init_and_add() allocates a kobject name for each space_info sub-group. When those sub-group objects are later removed, the vulnerable code frees the structure directly instead of removing the sysfs kobject correctly with kobject_put(), leaving the allocated kobject name memory unreleased. A local user with sufficient privileges to trigger Btrfs mount/configuration paths can repeatedly exercise the affected code path and consume kernel memory over time, potentially causing system instability or denial of service. The issue has low EPSS, no known public exploit maturity, and is not listed in CISA KEV.

Why it matters to the business

Successful exploitation can degrade or interrupt Linux systems that use or allow Btrfs operations by steadily exhausting kernel memory, potentially leading to service outages, host instability, failed workloads, or emergency reboots. The risk is mainly operational availability rather than data theft or data modification. Exposure is highest on multi-user systems, container hosts, build/test infrastructure, or environments where untrusted users or workloads can create, mount, or manipulate Btrfs filesystems. Because the flaw is local and currently has low exploitation likelihood, it is generally a routine-priority kernel maintenance issue unless Btrfs mount capabilities are available to less-trusted users.

How an attack unfolds

An attacker first needs local access to a vulnerable Linux system and enough privilege or delegated capability to trigger Btrfs filesystem mount or fsconfig operations. They then repeatedly create or mount Btrfs filesystems in a way that causes Btrfs space_info sub-groups to be initialized and later removed. On vulnerable kernels, cleanup does not release the kobject name allocated for each affected sub-group, so each cycle leaks a small amount of kernel memory. By automating the trigger loop, the attacker can accumulate unreclaimed kernel allocations until memory pressure affects the host. Depending on workload and available memory, the result may be degraded performance, allocation failures, service crashes, or a system-wide denial of service requiring reboot. There is no indication from the provided intelligence that this vulnerability enables privilege escalation, code execution, or data compromise.

How to fix it

Update the Linux kernel to a vendor release that includes the Btrfs fix for this issue. The corrective change ensures Btrfs removes space_info sub-group sysfs objects through the proper Btrfs sysfs removal path so kobject references and names are released correctly. No exact fixed package versions were provided, so use distribution vendor advisories and kernel changelogs for the affected Linux kernel packages. Where immediate patching is not possible, reduce exposure by restricting local users and containers from mounting or configuring Btrfs filesystems, limiting CAP_SYS_ADMIN delegation, disabling unprivileged user namespaces where appropriate, avoiding Btrfs availability in untrusted workloads, and monitoring for repeated Btrfs mount/teardown activity. Kernel mitigations should be treated as temporary; rebooting into a fixed kernel is required to fully remediate a running vulnerable kernel.

How to confirm the fix worked

Confirm remediation by verifying the running kernel version is at or above the vendor-fixed release and that the system has rebooted into that fixed kernel. Review vendor package metadata or kernel changelogs for the Btrfs patch that replaces direct freeing of space_info sub-group elements with btrfs_sysfs_remove_space_info() cleanup. On test systems, reproduce validation only in a controlled environment by running Btrfs mount/teardown stress tests with CONFIG_DEBUG_KMEMLEAK enabled and confirming that kmemleak no longer reports leaked kobject name allocations in the Btrfs space_info path. For exposure validation, inventory systems with Btrfs enabled or loaded, check whether untrusted users or containers can perform mount/fsconfig operations, and confirm controls prevent non-administrative Btrfs mount activity.

Typical attack path

1. Gain local authenticated access to a Linux system running an affected kernel with Btrfs support.
2. Obtain or use existing permissions that allow mounting, configuring, or repeatedly manipulating Btrfs filesystems, such as mount-related privileges, CAP_SYS_ADMIN, or an overly permissive container/user-namespace configuration.
3. Trigger Btrfs filesystem initialization paths that create space_info sub-group sysfs kobjects.
4. Trigger removal or teardown of those Btrfs space_info sub-groups.
5. Repeat the mount/configuration/teardown sequence to leak kernel memory over time.
6. Continue until kernel memory pressure causes degraded performance, failed allocations, service disruption, or host instability.

How to detect it

Detection should focus on signs of prior or ongoing denial-of-service attempts and evidence of the vulnerable leak path. Review auditd, systemd journal, kernel logs, and command/process telemetry for repeated Btrfs mount, fsconfig, unmount, or filesystem creation activity, especially by unexpected non-administrative users or containers. Look for rapid loops involving mount, umount, fsconfig, btrfs, mkfs.btrfs, losetup, or test tools that repeatedly create and tear down Btrfs filesystems. In kernel logs, investigate memory pressure, out-of-memory events, allocation failures, or instability that follows repeated Btrfs mount activity. On debug or lab kernels with kmemleak enabled, search for kmemleak reports referencing kobject name allocations in the Btrfs space_info path, particularly btrfs_sysfs_add_space_info_type(), create_space_info_sub_group(), create_space_info(), btrfs_init_space_info(), open_ctree(), btrfs_get_tree(), vfs_cmd_create(), __do_sys_fsconfig(), or process name mount. Because the leak is small and generic, there may be no unique artifact on production systems; absence of these indicators does not prove non-exploitation.

• btrfs_sysfs_add_space_info_type
• create_space_info_sub_group
• create_space_info
• btrfs_init_space_info
• open_ctree
• btrfs_get_tree
• vfs_cmd_create
• __do_sys_fsconfig
• kobject_init_and_add
• kobject_set_name_vargs
• kstrdup
• unreferenced object
• comm "mount"
• data-reloc
• CONFIG_DEBUG_KMEMLEAK
• kmemleak
• Out of memory
• invoked oom-killer
• mkfs.btrfs
• mount -t btrfs
• umount
• fsconfig(

What your security team should do

• Inventory Linux systems with Btrfs enabled, Btrfs filesystems mounted, or workloads that can create and mount Btrfs filesystems.
• Prioritize patching shared, multi-user, container-host, CI/CD, lab, and test systems where less-trusted users or workloads may have mount-related privileges.
• Upgrade affected Linux kernel packages to vendor-fixed releases and reboot systems into the fixed kernel.
• Restrict CAP_SYS_ADMIN, mount privileges, privileged containers, and unprivileged user namespace configurations that could allow untrusted workloads to trigger Btrfs mount paths.
• Temporarily avoid exposing Btrfs mount/configuration capability to untrusted users until fixed kernels are deployed.
• Monitor for repeated mount, fsconfig, unmount, or Btrfs-related activity from unexpected users or processes.
• Track vendor advisories because fixed versions vary by Linux distribution and kernel branch.
• Treat this as an availability-risk issue with currently low exploitation likelihood, but escalate priority where Btrfs operations are exposed to untrusted local users.