* [PATCH] btrfs: fix leak of kobject name for sub-group space_info
@ 2026-03-01 12:17 Shin'ichiro Kawasaki
2026-03-02 10:13 ` Johannes Thumshirn
2026-03-02 10:16 ` Filipe Manana
0 siblings, 2 replies; 5+ messages in thread
From: Shin'ichiro Kawasaki @ 2026-03-01 12:17 UTC (permalink / raw)
To: linux-btrfs, David Sterba
Cc: Naohiro Aota, Johannes Thumshirn, Shin'ichiro Kawasaki
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]);
space_info->sub_group[i] = NULL;
}
}
--
2.53.0
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] btrfs: fix leak of kobject name for sub-group space_info
2026-03-01 12:17 [PATCH] btrfs: fix leak of kobject name for sub-group space_info Shin'ichiro Kawasaki
@ 2026-03-02 10:13 ` Johannes Thumshirn
2026-03-02 10:16 ` Filipe Manana
1 sibling, 0 replies; 5+ messages in thread
From: Johannes Thumshirn @ 2026-03-02 10:13 UTC (permalink / raw)
To: Shinichiro Kawasaki, linux-btrfs@vger.kernel.org, David Sterba
Cc: Naohiro Aota
Looks good,
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] btrfs: fix leak of kobject name for sub-group space_info
2026-03-01 12:17 [PATCH] btrfs: fix leak of kobject name for sub-group space_info Shin'ichiro Kawasaki
2026-03-02 10:13 ` Johannes Thumshirn
@ 2026-03-02 10:16 ` Filipe Manana
2026-03-02 10:19 ` Johannes Thumshirn
1 sibling, 1 reply; 5+ messages in thread
From: Filipe Manana @ 2026-03-02 10:16 UTC (permalink / raw)
To: Shin'ichiro Kawasaki
Cc: linux-btrfs, David Sterba, Naohiro Aota, Johannes Thumshirn
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()?
> space_info->sub_group[i] = NULL;
> }
> }
> --
> 2.53.0
>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] btrfs: fix leak of kobject name for sub-group space_info
2026-03-02 10:16 ` Filipe Manana
@ 2026-03-02 10:19 ` Johannes Thumshirn
2026-03-02 10:51 ` Shinichiro Kawasaki
0 siblings, 1 reply; 5+ messages in thread
From: Johannes Thumshirn @ 2026-03-02 10:19 UTC (permalink / raw)
To: Filipe Manana, Shinichiro Kawasaki
Cc: linux-btrfs@vger.kernel.org, David Sterba, Naohiro Aota
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] btrfs: fix leak of kobject name for sub-group space_info
2026-03-02 10:19 ` Johannes Thumshirn
@ 2026-03-02 10:51 ` Shinichiro Kawasaki
0 siblings, 0 replies; 5+ messages in thread
From: Shinichiro Kawasaki @ 2026-03-02 10:51 UTC (permalink / raw)
To: Johannes Thumshirn
Cc: Filipe Manana, linux-btrfs@vger.kernel.org, David Sterba,
Naohiro Aota
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2026-03-02 10:51 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-03-01 12:17 [PATCH] btrfs: fix leak of kobject name for sub-group space_info Shin'ichiro Kawasaki
2026-03-02 10:13 ` Johannes Thumshirn
2026-03-02 10:16 ` Filipe Manana
2026-03-02 10:19 ` Johannes Thumshirn
2026-03-02 10:51 ` Shinichiro Kawasaki
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox