Re: [PATCH] btrfs: fix leak of kobject name for sub-group space_info

[Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com>]

On Mar 02, 2026 / 10:19, Johannes Thumshirn wrote:
> On 3/2/26 11:17 AM, Filipe Manana wrote:
> > On Sun, Mar 1, 2026 at 12:17 PM Shin'ichiro Kawasaki
> > <shinichiro.kawasaki@wdc.com> wrote:
> >> When create_space_info_sub_group() allocates elements of
> >> space_info->sub_group[], kobject_init_and_add() is called for each
> >> element via btrfs_sysfs_add_space_info_type(). However, when
> >> check_removing_space_info() frees these elements, it does not call
> >> btrfs_sysfs_remove_space_info() on them. As a result, kobject_put() 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 CONFIG_DEBUG_KMEMLEAK. 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):
> >>      __kmalloc_node_track_caller_noprof+0x619/0x870
> >>      kstrdup+0x42/0xc0
> >>      kobject_set_name_vargs+0x44/0x110
> >>      kobject_init_and_add+0xcf/0x150
> >>      btrfs_sysfs_add_space_info_type+0xfc/0x210 [btrfs]
> >>      create_space_info_sub_group.constprop.0+0xfb/0x1b0 [btrfs]
> >>      create_space_info+0x211/0x320 [btrfs]
> >>      btrfs_init_space_info+0x15a/0x1b0 [btrfs]
> >>      open_ctree+0x33c7/0x4a50 [btrfs]
> >>      btrfs_get_tree.cold+0x9f/0x1ee [btrfs]
> >>      vfs_get_tree+0x87/0x2f0
> >>      vfs_cmd_create+0xbd/0x280
> >>      __do_sys_fsconfig+0x3df/0x990
> >>      do_syscall_64+0x136/0x1540
> >>      entry_SYSCALL_64_after_hwframe+0x76/0x7e
> >>
> >> To avoid the leak, call btrfs_sysfs_remove_space_info() instead of
> >> kfree() for the elements.
> >>
> >> Fixes: f92ee31e031c ("btrfs: introduce btrfs_space_info sub-group")
> >> Closes: https://lore.kernel.org/linux-block/b9488881-f18d-4f47-91a5-3c9bf63955a5@wdc.com/
> >> Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
> >> ---
> >>   fs/btrfs/block-group.c | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/fs/btrfs/block-group.c b/fs/btrfs/block-group.c
> >> index c284f48cfae4..35e65e277f53 100644
> >> --- a/fs/btrfs/block-group.c
> >> +++ b/fs/btrfs/block-group.c
> >> @@ -4548,7 +4548,7 @@ static void check_removing_space_info(struct btrfs_space_info *space_info)
> >>                  for (int i = 0; i < BTRFS_SPACE_INFO_SUB_GROUP_MAX; i++) {
> >>                          if (space_info->sub_group[i]) {
> >>                                  check_removing_space_info(space_info->sub_group[i]);
> >> -                               kfree(space_info->sub_group[i]);
> >> +                               btrfs_sysfs_remove_space_info(space_info->sub_group[i]);
> > This doesn't feel right.
> >
> > The kfree() should still be there, we just need to call
> > btrfs_sysfs_remove_space_info() before the kfree.
> > Otherwise how do you release the memory for the sub group we allocated
> > with kzalloc_obj() in create_space_info_sub_group()?
> No, I thought so as well, but then Shin'ichiro told me he did that too, 
> but then KASAN complains about a double-free.

Right, I observed the double-free when I left the kfree() call.

I think the memory is released by space_info_release(), which is the member of
'static const struct kobj_type space_info_ktype'. This ktype is registered to
the kobject when btrfs_sysfs_add_space_info_type() calls
kobject_init_and_type(). When btrfs_sysfs_remove_space_info() calls
kobject_put(), the last reference is gone and the memory is released.