Received-SPF: pass (google.com: domain of linux-kernel+bounces-183996-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Mon, 20 May 2024 19:18:48 +0200
From: Nam Cao <namcao@linutronix.de>
To: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
Cc: syzbot <syzbot+83763e624cfec6b462cb@syzkaller.appspotmail.com>,
	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)
Message-ID: <20240520171848.60Nzvv8y@linutronix.de>
References: <000000000000809328060a8a4c1c@google.com>
 <20240520144641.17643-1-n.zhandarovich@fintech.ru>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240520144641.17643-1-n.zhandarovich@fintech.ru>

On Mon, May 20, 2024 at 07:46:41AM -0700, Nikita Zhandarovich wrote:
> 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?

Possibly this is because the driver's probe function doesn't clean up
itself properly if it fails in the middle (e.g. due to the system running
out of memory and kmalloc() fails). These aren't easy to reproduce, because
you would need to make probing fails somehow.

Example fix: ac83631230f7 ("staging: r8712: Fix memory leak in
_r8712_init_xmit_priv()")

Best regards,
Nam