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


Powered by blists - more mailing lists