Received-SPF: pass (google.com: domain of linux-kernel+bounces-183857-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
From: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
To: syzbot <syzbot+83763e624cfec6b462cb@syzkaller.appspotmail.com>
CC: Nikita Zhandarovich <n.zhandarovich@fintech.ru>,
	<Larry.Finger@lwfinger.net>, <florian.c.schilhabel@googlemail.com>,
	<gregkh@linuxfoundation.org>, <linux-kernel@vger.kernel.org>,
	<linux-media@vger.kernel.org>, <linux-staging@lists.linux.dev>,
	<linux-usb@vger.kernel.org>, <syzkaller-bugs@googlegroups.com>
Subject: Re: [syzbot] [staging?] [usb?] memory leak in _r8712_init_xmit_priv (2)
Date: Mon, 20 May 2024 07:46:41 -0700
Message-ID: <20240520144641.17643-1-n.zhandarovich@fintech.ru>
In-Reply-To: <000000000000809328060a8a4c1c@google.com>
References:
Precedence: bulk
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain

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