CVE-2026-31434: btrfs: fix leak of kobject name for sub-group space_info
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix leak of kobject name for sub-group spaceinfo
When createspaceinfosubgroup() allocates elements of spaceinfo->subgroup[], kobjectinitandadd() is called for each element via btrfssysfsaddspaceinfotype(). However, when checkremovingspaceinfo() frees these elements, it does not call btrfssysfsremovespaceinfo() on them. As a result, kobjectput() is not called and the associated kobj->name objects are leaked.
This memory leak is reproduced by running the blktests test case zbd/009 on kernels built with CONFIGDEBUGKMEMLEAK. The kmemleak feature reports the following error:
unreferenced object 0xffff888112877d40 (size 16): comm "mount", pid 1244, jiffies 4294996972 hex dump (first 16 bytes): 64 61 74 61 2d 72 65 6c 6f 63 00 c4 c6 a7 cb 7f data-reloc...... backtrace (crc 53ffde4d): kmallocnodetrackcallernoprof+0x619/0x870 kstrdup+0x42/0xc0 kobjectsetnamevargs+0x44/0x110 kobjectinitandadd+0xcf/0x150 btrfssysfsaddspaceinfotype+0xfc/0x210 [btrfs] createspaceinfosubgroup.constprop.0+0xfb/0x1b0 [btrfs] createspaceinfo+0x211/0x320 [btrfs] btrfsinitspaceinfo+0x15a/0x1b0 [btrfs] openctree+0x33c7/0x4a50 [btrfs] btrfsgettree.cold+0x9f/0x1ee [btrfs] vfsgettree+0x87/0x2f0 vfscmdcreate+0xbd/0x280 dosysfsconfig+0x3df/0x990 dosyscall64+0x136/0x1540 entrySYSCALL64afterhwframe+0x76/0x7e
To avoid the leak, call btrfssysfsremovespaceinfo() instead of kfree() for the elements.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.1.176-1Fixed in 6.1.190-1Fixed in 6.12.107-1Fixed in 6.12.113-1Fixed in 7.2.12-1Fixed in 7.2.13-1 - Compensating control
In btrfs check_removing_space_info(), call btrfs_sysfs_remove_space_info() instead of kfree() for space_info->sub_group[] elements, ensuring the associated kobject names are released.
Event History
Frequently Asked Questions
What systems are exposed to this issue?
Systems using the Linux kernel with Btrfs and sub-group space_info objects can be affected. The leak is triggered during creation and later removal of elements in space_info->sub_group[].
What access does an attacker need to exploit the impact?
The vector is local and requires low privileges. No user interaction is required, and the reported impact is memory exhaustion leading to denial of service; no confidentiality or integrity impact is identified.
How can I determine whether the leak is occurring?
The leak was reproduced with the blktests zbd/009 test on a kernel built with CONFIG_DEBUG_KMEMLEAK. Kmemleak reports unreferenced 16-byte kobject name allocations originating from kstrdup, kobject_set_name_vargs, and btrfs_sysfs_add_space_info_type.
What is the remediation?
Update to a kernel containing the fix referenced by the listed stable kernel commits. The correction ensures the sub-group space_info elements are removed through the corresponding sysfs cleanup path so kobject_put() is called.