Re: [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@xxxxxxxxxx> 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@xxxxxxxxx>
> > >
> > > 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/