[Linux Kernel Bug] memory leak in ubi_attach

[Zhihao Cheng]

在 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 at huawei.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 at gmail.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/