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
| ||
|
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