linux-kernel - Re: [PATCH v4 3/3] mm/slub: Fix memory leak of kobj->name in sysfs_slab

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <02820eb8-0b8f-4aa8-9315-85368e9c331e@suse.cz>
Date: Fri, 13 Sep 2024 16:10:08 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Jinjie Ruan <ruanjinjie@...wei.com>, Hyeonggon Yoo <42.hyeyoo@...il.com>
Cc: Liu Shixin <liushixin2@...wei.com>, Christoph Lameter <cl@...ux.com>,
 Pekka Enberg <penberg@...nel.org>, David Rientjes <rientjes@...gle.com>,
 Joonsoo Kim <iamjoonsoo.kim@....com>,
 Andrew Morton <akpm@...ux-foundation.org>,
 Roman Gushchin <roman.gushchin@...ux.dev>, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 3/3] mm/slub: Fix memory leak of kobj->name in
 sysfs_slab_add()

On 9/6/24 10:10, Jinjie Ruan wrote:
> 
> 
> On 2024/9/5 21:59, Hyeonggon Yoo wrote:
>> On Thu, Sep 5, 2024 at 12:41 PM Jinjie Ruan <ruanjinjie@...wei.com> wrote:
>>>
>>>
>>>
>>> On 2022/11/12 19:46, Liu Shixin wrote:
>>>> There is a memory leak of kobj->name in sysfs_slab_add():
>>>>
>>>>  unreferenced object 0xffff88817e446440 (size 32):
>>>>    comm "insmod", pid 4085, jiffies 4296564501 (age 126.272s)
>>>>    hex dump (first 32 bytes):
>>>>      75 62 69 66 73 5f 69 6e 6f 64 65 5f 73 6c 61 62  ubifs_inode_slab
>>>>      00 65 44 7e 81 88 ff ff 00 00 00 00 00 00 00 00  .eD~............
>>>>    backtrace:
>>>>      [<000000005b30fbbd>] __kmalloc_node_track_caller+0x4e/0x150
>>>>      [<000000002f70da0c>] kstrdup_const+0x4b/0x80
>>>>      [<00000000c6712c61>] kobject_set_name_vargs+0x2f/0xb0
>>>>      [<00000000b151218e>] kobject_init_and_add+0xb0/0x120
>>>>      [<00000000e56a4cf5>] sysfs_slab_add+0x17d/0x220
>>>>      [<000000009326fd57>] __kmem_cache_create+0x406/0x590
>>>>      [<00000000dde33cff>] kmem_cache_create_usercopy+0x1fc/0x300
>>>>      [<00000000fe90cedb>] kmem_cache_create+0x12/0x20
>>>>      [<000000007a6531c8>] 0xffffffffa02d802d
>>>>      [<000000000e3b13c7>] do_one_initcall+0x87/0x2a0
>>>>      [<00000000995ecdcf>] do_init_module+0xdf/0x320
>>>>      [<000000008821941f>] load_module+0x2f98/0x3330
>>>>      [<00000000ef51efa4>] __do_sys_finit_module+0x113/0x1b0
>>>>      [<000000009339fbce>] do_syscall_64+0x35/0x80
>>>>      [<000000006b7f2033>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
>>>
>>>
>>> Hi，every one,
>> 
>> Hi.
>> 
>>> I found the same problem and it solve this problem with the patch, is
>>> there any plan to update the patch and solve it.

Hmm looks like back in 2022, Hyeonggon had some feedback to the series which
was not answered and then it got forgotten. Feel free to take over and send
an updated version.

>> What kernel version do you use,
> 
> 6.11.0-rc6
> 
>> and when do you encounter it or how do you reproduce it?
> 
> Hi, Hyeonggon,
> 
> Thank you, I encounter it when doing inject fault test while modprobe
> amdgpu.ko.

So I wonder where's the problem that results in kobject_init_and_add()
failing. If it's genuinely duplicate name as commit 80da026a8e5d suggests,
6.12-rc1 will have a warning to prevent that. Delayed destruction of
SLAB_TYPESAFE_BY_RCU caches should also no longer happen with 6.12-rc1. So
worth retrying with that and if it's still failing, we should look at the
root cause perhaps.

>> 
>> --
>> Hyeonggon