[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7138a98c-1562-3059-07b6-4d918bec9d1a@huawei.com>
Date: Wed, 24 Jan 2024 20:44:36 +0800
From: Zhihao Cheng <chengzhihao1@...wei.com>
To: Chenyuan Yang <chenyuan0y@...il.com>
CC: <linux-mtd@...ts.infradead.org>, <richard@....at>,
<miquel.raynal@...tlin.com>, <vigneshr@...com>,
<linux-kernel@...r.kernel.org>, <syzkaller@...glegroups.com>, Zijie Zhao
<zzjas98@...il.com>
Subject: Re: [Linux Kernel Bug] memory leak in ubi_attach
在 2024/1/23 12:57, Chenyuan Yang 写道:
> Hi Zhihao,
>
> Thanks for your prompt reply! Here are the files related to this memory leak.
>
> Best,
> Chenyuan
>
Can you provide a kernel config and the cmdline? I can't reproduce the
problem by both C program and syz program. But after analyzing the log:
[<ffffffff8157274e>] __kmalloc_node_track_caller+0x4e/0x120
mm/slab_common.c:1027
[<ffffffff81561e1f>] kstrdup+0x3f/0x70 mm/util.c:62
[<ffffffff81561ea7>] kstrdup_const+0x57/0x80 mm/util.c:85
[<ffffffff824d4596>] kvasprintf_const+0xc6/0x110 lib/kasprintf.c:48
[<ffffffff84aaeadf>] kobject_set_name_vargs+0x3f/0xe0 lib/kobject.c:272
[<ffffffff84aaef41>] kobject_add_varg lib/kobject.c:366 [inline]
[<ffffffff84aaef41>] kobject_init_and_add+0x71/0xe0 lib/kobject.c:455
[<ffffffff8162085a>] sysfs_slab_add+0x10a/0x210 mm/slub.c:6168
[<ffffffff81628474>] __kmem_cache_create+0x1b4/0x5a0 mm/slub.c:5120
[<ffffffff81571dca>] create_cache mm/slab_common.c:235 [inline]
[<ffffffff81571dca>] kmem_cache_create_usercopy+0x16a/0x2e0
mm/slab_common.c:340
[<ffffffff81571f51>] kmem_cache_create+0x11/0x20 mm/slab_common.c:395
[<ffffffff82e40fc5>] alloc_ai drivers/mtd/ubi/attach.c:1464 [inline]
[<ffffffff82e40fc5>] ubi_attach+0xb5/0x1e00
drivers/mtd/ubi/attach.c:1560
[<ffffffff82e302f8>] ubi_attach_mtd_dev+0x878/0x1130
drivers/mtd/ubi/build.c:1000
[<ffffffff82e3176d>] ctrl_cdev_ioctl+0x1dd/0x250
drivers/mtd/ubi/cdev.c:1043
[<ffffffff816b0e23>] vfs_ioctl fs/ioctl.c:51 [inline]
[<ffffffff816b0e23>] __do_sys_ioctl fs/ioctl.c:871 [inline]
The leaked memory is located in 'kobj->name', the kobj comes from
kmem_cache and it is used to create entry under
sysfs('/sys/kernel/slab'). If kmem_cache_destroy() is missed to be
called in someone exiting path in UBI, there will be more memleak
messages reported (eg. ai->aeb_slab_cache). So I guess the potentional
problem has nothing to do with UBI.
After looking through the implementation of create_cache, the life time
of 'kobj->name' is along with kobj, it can be always released even in
error handling paths. To figure out what happens I need to reproduce it
on my local machine.
> On Mon, Jan 22, 2024 at 10:55 PM Zhihao Cheng <chengzhihao1@...wei.com> wrote:
>>
>> 在 2024/1/23 11:53, Chenyuan Yang 写道:
>>> Dear Linux Kernel Developers for UBI,
>>>
>>> We encountered "memory leak in ubi_attach" when testing UBI with
>>> Syzkaller and our generated specifications.
>>>
>>> syz repro: https://drive.google.com/file/d/17FoGw6akfufz05U-oRBP2wXmOiFF1VUq/view?usp=drive_link
>>> C reproducer: https://drive.google.com/file/d/1ayd3lmHPvqNoI01pQEdU832EktpTUnZ_/view?usp=drive_link
>>> report: https://drive.google.com/file/d/1hC2arY3FbQt-6L5rbDfY-DQ2oH82IIGq/view?usp=drive_link
>>> stats: https://drive.google.com/file/d/1REig9fV0H1fYPWaiicc-JVLlCpo7TTw4/view?usp=drive_link
>>
>> I can't open above links in company, may you post these files in attachment?
>>
>>>
>>> This memory leak is triggered by `ioctl$UBI_IOCATT`, where
>>> `ubi_attach_info` invokes `kmem_cache_create`
>>> (https://elixir.bootlin.com/linux/v6.7/source/drivers/mtd/ubi/attach.c#L1464).
>>> It seems that the memory leak occurs when the slab cache is
>>> successfully created. I apologize for not being able to conduct a
>>> deeper analysis of the root cause, as my expertise in UBI drivers is
>>> limited.
>>>
>>> If you have any questions or require more information, please feel
>>> free to contact us.
>>>
>>> Reported-by: Chenyuan Yang <chenyuan0y@...il.com>
>>>
>>> Best,
>>> Chenyuan
>>>
>>>
>>> ______________________________________________________
>>> Linux MTD discussion mailing list
>>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>>>
>>
>>
>> ______________________________________________________
>> Linux MTD discussion mailing list
>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
Powered by blists - more mailing lists