[Linux Kernel Bug] memory leak in ubi_attach

Wed Jan 24 06:41:00 PST 2024

Hi Zhihao,

Thanks very much for your reply and further exploration of this crash!

I have attached the config to reproduce this memory leak. For the
command line, you can use qemu to boot the kernel (You need to build
the bullseye-image first).
```
mkdir -p logs
qemu-system-x86_64 \
-m 2G \
-smp 2 \
-kernel linux/arch/x86/boot/bzImage \
-append "console=ttyS0 root=/dev/sda earlyprintk=serial net.ifnames=0" \
-drive file=image/bullseye-qemu.img,format=raw \
-net user,host=10.0.2.10,hostfwd=tcp:127.0.0.1:10021-:22 \
-net nic,model=e1000 \
-enable-kvm \
-nographic \
-pidfile vm.pid \
```

In qemu, you can run
```
gcc -pthread repro.c -o exe
./exe
```
to reproduce the memory leak.

Feel free to contact me if you have any questions.

Best,
Chenyuan

On Wed, Jan 24, 2024 at 6:44 AM Zhihao Cheng <chengzhihao1 at huawei.com> wrote:
>
> 在 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/
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config
Type: application/octet-stream
Size: 242732 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20240124/695f9530/attachment-0001.obj>