linux-kernel - Re: [syzbot] [staging?] [usb?] memory leak in _r8712_init_xmit

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Mon, 20 May 2024 07:46:41 -0700
From: Nikita Zhandarovich <n.zhandarovich@...tech.ru>
To: syzbot <syzbot+83763e624cfec6b462cb@...kaller.appspotmail.com>
CC: Nikita Zhandarovich <n.zhandarovich@...tech.ru>,
	<Larry.Finger@...inger.net>, <florian.c.schilhabel@...glemail.com>,
	<gregkh@...uxfoundation.org>, <linux-kernel@...r.kernel.org>,
	<linux-media@...r.kernel.org>, <linux-staging@...ts.linux.dev>,
	<linux-usb@...r.kernel.org>, <syzkaller-bugs@...glegroups.com>
Subject: Re: [syzbot] [staging?] [usb?] memory leak in _r8712_init_xmit_priv (2)

Hi,

> BUG: memory leak
> unreferenced object 0xffff888107a5c000 (size 4096):
>   comm "kworker/1:0", pid 22, jiffies 4294943134 (age 18.720s)
>   hex dump (first 32 bytes):
>     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>   backtrace:
>     [<ffffffff816337cd>] kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline]
>     [<ffffffff816337cd>] slab_post_alloc_hook mm/slab.h:766 [inline]
>     [<ffffffff816337cd>] slab_alloc_node mm/slub.c:3478 [inline]
>     [<ffffffff816337cd>] __kmem_cache_alloc_node+0x2dd/0x3f0 mm/slub.c:3517
>     [<ffffffff8157e625>] kmalloc_trace+0x25/0x90 mm/slab_common.c:1098
>     [<ffffffff83cee442>] kmalloc include/linux/slab.h:600 [inline]
>     [<ffffffff83cee442>] _r8712_init_xmit_priv+0x2b2/0x6e0 drivers/staging/rtl8712/rtl871x_xmit.c:130
>     [<ffffffff83ce9033>] r8712_init_drv_sw+0xc3/0x290 drivers/staging/rtl8712/os_intfs.c:311
>     [<ffffffff83ce7ce6>] r871xu_drv_init+0x1c6/0x920 drivers/staging/rtl8712/usb_intf.c:386
>     [<ffffffff832d0f0b>] usb_probe_interface+0x16b/0x3a0 drivers/usb/core/driver.c:396
>     [<ffffffff82c3bb06>] call_driver_probe drivers/base/dd.c:579 [inline]

I am inclined to think that this issue might be false positive. During
repro the device is initialized correctly, does some work and then
exits, calling all required functions to clean things up
(i.e. _free_xmit_priv()), including pxmitbuf->pallocated_buf.
Kmemleak triggers disappear if you set longer intervals between
scannning for them (obviously). And if all the things get cleared up
when the device disconnects, isn't that correct and expected
behaviour? Could the scanner just "lose track" of some of the objects
here?

Or am I missing something?

Regards,
Nikita