Hello,
syzbot found the following issue on:
HEAD commit: c42d9eeef8e5 Merge tag 'hardening-v6.7-rc2' of git://git.k..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13bff22f680000
kernel config: https://syzkaller.appspot.com/x/.config?x=e71d284dd6560ca8
dashboard link: https://syzkaller.appspot.com/bug?extid=83763e624cfec6b462cb
compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1564223f680000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17a7c024e80000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/026cc0fc446f/disk-c42d9eee.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/c4b4d6d092c1/vmlinux-c42d9eee.xz
kernel image: https://storage.googleapis.com/syzbot-assets/1865f885e9d6/bzImage-c42d9eee.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: [email protected]
executing program
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]
[<ffffffff82c3bb06>] really_probe+0x126/0x440 drivers/base/dd.c:658
[<ffffffff82c3bee3>] __driver_probe_device+0xc3/0x190 drivers/base/dd.c:800
[<ffffffff82c3bfda>] driver_probe_device+0x2a/0x120 drivers/base/dd.c:830
[<ffffffff82c3c1d4>] __device_attach_driver+0x104/0x160 drivers/base/dd.c:958
[<ffffffff82c38f5d>] bus_for_each_drv+0xcd/0x120 drivers/base/bus.c:457
[<ffffffff82c3c6fa>] __device_attach+0xfa/0x290 drivers/base/dd.c:1030
[<ffffffff82c3a6ca>] bus_probe_device+0xca/0xd0 drivers/base/bus.c:532
[<ffffffff82c36b7e>] device_add+0x9be/0xc90 drivers/base/core.c:3625
[<ffffffff832cdfd7>] usb_set_configuration+0x967/0xc70 drivers/usb/core/message.c:2207
[<ffffffff832e0cac>] usb_generic_driver_probe+0x9c/0xf0 drivers/usb/core/generic.c:238
BUG: memory leak
unreferenced object 0xffff888107a59000 (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]
[<ffffffff82c3bb06>] really_probe+0x126/0x440 drivers/base/dd.c:658
[<ffffffff82c3bee3>] __driver_probe_device+0xc3/0x190 drivers/base/dd.c:800
[<ffffffff82c3bfda>] driver_probe_device+0x2a/0x120 drivers/base/dd.c:830
[<ffffffff82c3c1d4>] __device_attach_driver+0x104/0x160 drivers/base/dd.c:958
[<ffffffff82c38f5d>] bus_for_each_drv+0xcd/0x120 drivers/base/bus.c:457
[<ffffffff82c3c6fa>] __device_attach+0xfa/0x290 drivers/base/dd.c:1030
[<ffffffff82c3a6ca>] bus_probe_device+0xca/0xd0 drivers/base/bus.c:532
[<ffffffff82c36b7e>] device_add+0x9be/0xc90 drivers/base/core.c:3625
[<ffffffff832cdfd7>] usb_set_configuration+0x967/0xc70 drivers/usb/core/message.c:2207
[<ffffffff832e0cac>] usb_generic_driver_probe+0x9c/0xf0 drivers/usb/core/generic.c:238
BUG: memory leak
unreferenced object 0xffff888108475000 (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]
[<ffffffff82c3bb06>] really_probe+0x126/0x440 drivers/base/dd.c:658
[<ffffffff82c3bee3>] __driver_probe_device+0xc3/0x190 drivers/base/dd.c:800
[<ffffffff82c3bfda>] driver_probe_device+0x2a/0x120 drivers/base/dd.c:830
[<ffffffff82c3c1d4>] __device_attach_driver+0x104/0x160 drivers/base/dd.c:958
[<ffffffff82c38f5d>] bus_for_each_drv+0xcd/0x120 drivers/base/bus.c:457
[<ffffffff82c3c6fa>] __device_attach+0xfa/0x290 drivers/base/dd.c:1030
[<ffffffff82c3a6ca>] bus_probe_device+0xca/0xd0 drivers/base/bus.c:532
[<ffffffff82c36b7e>] device_add+0x9be/0xc90 drivers/base/core.c:3625
[<ffffffff832cdfd7>] usb_set_configuration+0x967/0xc70 drivers/usb/core/message.c:2207
[<ffffffff832e0cac>] usb_generic_driver_probe+0x9c/0xf0 drivers/usb/core/generic.c:238
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at [email protected].
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
For archival purposes, forwarding an incoming command email to
[email protected], [email protected].
***
Subject: printk debug
Author: [email protected]
#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
---
drivers/staging/rtl8712/rtl871x_xmit.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/rtl8712/rtl871x_xmit.c b/drivers/staging/rtl8712/rtl871x_xmit.c
index 6353dbe554d3..c80c60417d5c 100644
--- a/drivers/staging/rtl8712/rtl871x_xmit.c
+++ b/drivers/staging/rtl8712/rtl871x_xmit.c
@@ -125,6 +125,7 @@ int _r8712_init_xmit_priv(struct xmit_priv *pxmitpriv,
((addr_t)(pxmitpriv->pallocated_xmitbuf) & 3);
pxmitbuf = (struct xmit_buf *)pxmitpriv->pxmitbuf;
for (i = 0; i < NR_XMITBUFF; i++) {
+ pr_info("==> Allocating pallocated_buf %d\n", i);
INIT_LIST_HEAD(&pxmitbuf->list);
pxmitbuf->pallocated_buf =
kmalloc(MAX_XMITBUF_SZ + XMITBUF_ALIGN_SZ, GFP_ATOMIC);
@@ -188,6 +189,7 @@ void _free_xmit_priv(struct xmit_priv *pxmitpriv)
pxmitframe++;
}
for (i = 0; i < NR_XMITBUFF; i++) {
+ pr_info("==> Freeing pallocated_buf %d\n", i);
r8712_xmit_resource_free(padapter, pxmitbuf);
kfree(pxmitbuf->pallocated_buf);
pxmitbuf++;
--
2.25.1
For archival purposes, forwarding an incoming command email to
[email protected].
***
Subject: [syzbot] [staging?] [usb?] memory leak in _r8712_init_xmit_priv (2)
Author: [email protected]
Test to make sure the issue is still there.
#syz test
Hello,
syzbot has tested the proposed patch but the reproducer is still triggering an issue:
memory leak in corrupted
BUG: memory leak
unreferenced object 0xffff888109b12000 (size 4096):
comm "kworker/1:1", pid 28, jiffies 4294944675
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 (crc 0):
[<ffffffff815fa6f3>] kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline]
[<ffffffff815fa6f3>] slab_post_alloc_hook mm/slub.c:3817 [inline]
[<ffffffff815fa6f3>] slab_alloc_node mm/slub.c:3860 [inline]
[<ffffffff815fa6f3>] kmalloc_trace+0x283/0x330 mm/slub.c:4007
[<ffffffff83d23552>] kmalloc include/linux/slab.h:590 [inline]
[<ffffffff83d23552>] _r8712_init_xmit_priv+0x2b2/0x6e0 drivers/staging/rtl8712/rtl871x_xmit.c:130
[<ffffffff83d1e143>] r8712_init_drv_sw+0xc3/0x290 drivers/staging/rtl8712/os_intfs.c:310
[<ffffffff83d1ce06>] r871xu_drv_init+0x1c6/0x920 drivers/staging/rtl8712/usb_intf.c:386
[<ffffffff8330155b>] usb_probe_interface+0x16b/0x3a0 drivers/usb/core/driver.c:399
[<ffffffff82c6ef96>] call_driver_probe drivers/base/dd.c:579 [inline]
[<ffffffff82c6ef96>] really_probe+0x126/0x440 drivers/base/dd.c:658
[<ffffffff82c6f373>] __driver_probe_device+0xc3/0x190 drivers/base/dd.c:800
[<ffffffff82c6f46a>] driver_probe_device+0x2a/0x120 drivers/base/dd.c:830
[<ffffffff82c6f664>] __device_attach_driver+0x104/0x160 drivers/base/dd.c:958
[<ffffffff82c6c3bd>] bus_for_each_drv+0xcd/0x120 drivers/base/bus.c:457
[<ffffffff82c6fb8a>] __device_attach+0xfa/0x290 drivers/base/dd.c:1030
[<ffffffff82c6db2a>] bus_probe_device+0xca/0xd0 drivers/base/bus.c:532
[<ffffffff82c69fde>] device_add+0x9be/0xc90 drivers/base/core.c:3625
[<ffffffff832fe627>] usb_set_configuration+0x967/0xc70 drivers/usb/core/message.c:2207
[<ffffffff833110bf>] usb_generic_driver_probe+0x7f/0xd0 drivers/usb/core/generic.c:254
[<ffffffff83300c49>] usb_probe_device+0x79/0x180 drivers/usb/core/driver.c:294
BUG: memory leak
unreferenced object 0xffff888109b17000 (size 4096):
comm "kworker/1:1", pid 28, jiffies 4294944675
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 (crc 0):
[<ffffffff815fa6f3>] kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline]
[<ffffffff815fa6f3>] slab_post_alloc_hook mm/slub.c:3817 [inline]
[<ffffffff815fa6f3>] slab_alloc_node mm/slub.c:3860 [inline]
[<ffffffff815fa6f3>] kmalloc_trace+0x283/0x330 mm/slub.c:4007
[<ffffffff83d23552>] kmalloc include/linux/slab.h:590 [inline]
[<ffffffff83d23552>] _r8712_init_xmit_priv+0x2b2/0x6e0 drivers/staging/rtl8712/rtl871x_xmit.c:130
[<ffffffff83d1e143>] r8712_init_drv_sw+0xc3/0x290 drivers/staging/rtl8712/os_intfs.c:310
[<ffffffff83d1ce06>] r871xu_drv_init+0x1c6/0x920 drivers/staging/rtl8712/usb_intf.c:386
[<ffffffff8330155b>] usb_probe_interface+0x16b/0x3a0 drivers/usb/core/driver.c:399
[<ffffffff82c6ef96>] call_driver_probe drivers/base/dd.c:579 [inline]
[<ffffffff82c6ef96>] really_probe+0x126/0x440 drivers/base/dd.c:658
[<ffffffff82c6f373>] __driver_probe_device+0xc3/0x190 drivers/base/dd.c:800
[<ffffffff82c6f46a>] driver_probe_device+0x2a/0x120 drivers/base/dd.c:830
[<ffffffff82c6f664>] __device_attach_driver+0x104/0x160 drivers/base/dd.c:958
[<ffffffff82c6c3bd>] bus_for_each_drv+0xcd/0x120 drivers/base/bus.c:457
[<ffffffff82c6fb8a>] __device_attach+0xfa/0x290 drivers/base/dd.c:1030
[<ffffffff82c6db2a>] bus_probe_device+0xca/0xd0 drivers/base/bus.c:532
[<ffffffff82c69fde>] device_add+0x9be/0xc90 drivers/base/core.c:3625
[<ffffffff832fe627>] usb_set_configuration+0x967/0xc70 drivers/usb/core/message.c:2207
[<ffffffff833110bf>] usb_generic_driver_probe+0x7f/0xd0 drivers/usb/core/generic.c:254
[<ffffffff83300c49>] usb_probe_device+0x79/0x180 drivers/usb/core/driver.c:294
BUG: memory leak
unreferenced object 0xffff888109b15000 (size 4096):
comm "kworker/1:1", pid 28, jiffies 4294944675
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 (crc 0):
[<ffffffff815fa6f3>] kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline]
[<ffffffff815fa6f3>] slab_post_alloc_hook mm/slub.c:3817 [inline]
[<ffffffff815fa6f3>] slab_alloc_node mm/slub.c:3860 [inline]
[<ffffffff815fa6f3>] kmalloc_trace+0x283/0x330 mm/slub.c:4007
[<ffffffff83d23552>] kmalloc include/linux/slab.h:590 [inline]
[<ffffffff83d23552>] _r8712_init_xmit_priv+0x2b2/0x6e0 drivers/staging/rtl8712/rtl871x_xmit.c:130
[<ffffffff83d1e143>] r8712_init_drv_sw+0xc3/0x290 drivers/staging/rtl8712/os_intfs.c:310
[<ffffffff83d1ce06>] r871xu_drv_init+0x1c6/0x920 drivers/staging/rtl8712/usb_intf.c:386
[<ffffffff8330155b>] usb_probe_interface+0x16b/0x3a0 drivers/usb/core/driver.c:399
[<ffffffff82c6ef96>] call_driver_probe drivers/base/dd.c:579 [inline]
[<ffffffff82c6ef96>] really_probe+0x126/0x440 drivers/base/dd.c:658
[<ffffffff82c6f373>] __driver_probe_device+0xc3/0x190 drivers/base/dd.c:800
[<ffffffff82c6f46a>] driver_probe_device+0x2a/0x120 drivers/base/dd.c:830
[<ffffffff82c6f664>] __device_attach_driver+0x104/0x160 drivers/base/dd.c:958
[<ffffffff82c6c3bd>] bus_for_each_drv+0xcd/0x120 drivers/base/bus.c:457
[<ffffffff82c6fb8a>] __device_attach+0xfa/0x290 drivers/base/dd.c:1030
[<ffffffff82c6db2a>] bus_probe_device+0xca/0xd0 drivers/base/bus.c:532
[<ffffffff82c69fde>] device_add+0x9be/0xc90 drivers/base/core.c:3625
[<ffffffff832fe627>] usb_set_configuration+0x967/0xc70 drivers/usb/core/message.c:2207
[<ffffffff833110bf>] usb_generic_driver_probe+0x7f/0xd0 drivers/usb/core/generic.c:254
[<ffffffff83300c49>] usb_probe_device+0x79/0x180 drivers/usb/core/driver.c:294
Tested on:
commit: 9d1694dc Merge tag 'for-6.8/block-2024-01-18' of git:/..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=17b61b63e80000
kernel config: https://syzkaller.appspot.com/x/.config?x=447c03a4f5a8d571
dashboard link: https://syzkaller.appspot.com/bug?extid=83763e624cfec6b462cb
compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
Note: no patches were applied.
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
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
Hi,
On 5/20/24 10:18, Nam Cao wrote:
> 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
I did some more testing with the help of reproducer from [1].
The way I see it, during repro leaks supposedly occur this way:
r871xu_drv_init() // probe starts
...
r8712_init_drv_sw() // success at init
...
/* this takes around 20-30 secs during which LEAKS appear.
They only appear if repro tries to connect another similar
device in a loop. With only a single iteration no leaks are
present. */
for (i = 0, offset = 0; i < 128; i += 8, offset++)
r8712_efuse_pg_packet_read(padapter, offset,
&pdata[i]);
...
return 0; // probe succeeds
..
..
r871xu_dev_remove() // device starts disconnecting
...
r8712_free_drv_sw()
...
*/ clean up all the stuff that 'leaks'
_free_xmit_priv(&padapter->xmitpriv);
...
...
..
In short, I think that probe finishes fine (compared to an example you
brought up). But it is the interference from an attempt to connect a
similar device that throws off KMEMLEAK and triggers leaks. Currently I
can't figure out what exactly occurs to confuse the sanitizer.
P.S.
Test log during repro execution looks like this (please excuse some
crude and lazy debug printing on my part) with some added comments:
syz: main: finished sleeping, starting repro
// first process spawns, starts connecting device
syz: loop: pid 8532
[ 7420.475276][ T8518] usb 1-1: new high-speed USB device number 8 using
dummy_hcd
[ 7421.060451][ T8518] usb 1-1: New USB device found, idVendor=083a,
idProduct=c512, bcdDevice=cf.c8
[ 7421.064860][ T8518] usb 1-1: New USB device strings: Mfr=1,
Product=2, SerialNumber=3
[ 7421.068964][ T8518] usb 1-1: Product: syz
[ 7421.069828][ T8518] usb 1-1: Manufacturer: syz
[ 7421.070776][ T8518] usb 1-1: SerialNumber: syz
[ 7421.073606][ T8518] usb 1-1: config 0 descriptor??
[ 7421.109353][ T8518] r8712u: register rtl8712_netdev_ops to netdev_ops
[ 7421.110706][ T8518] usb 1-1: r8712u: USB_SPEED_HIGH with 0 endpoints
[ 7421.112160][ T8518] usb 1-1: r8712u: starting step 4 init_drv_sw
[ 7421.325368][ T8518] usb 1-1: r8712u: starting step 5 (efuze/eeprom etc)
[ 7421.545164][ T8518] usb 1-1: r8712u: Boot from EEPROM: Autoload OK
[ 7421.895138][ T8518] usb 1-1: r8712u: start read 128 efuse pg packets
// !!! syzbot repro spawns second process that tries to connect again
// while r8712_efuse_pg_packet_read() in probe() is run in a loop.
syz: loop: pid 8545
// !!! now KMEMLEAK messages appear
[ 7433.115796][ T8531] kmemleak: 12 new suspected memory leaks (see
/sys/kernel/debug/kmemleak)
BUG: memory leak
unreferenced object 0xffff88814a019000 (size 4096):
comm "kworker/0:0", pid 8518, jiffies 4295679317
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 (crc 0):
[<ffffffff81687c97>] kmalloc_trace+0x297/0x310
[<ffffffff83f45fb7>] _r8712_init_xmit_priv+0x2b7/0x700
[<ffffffff83f40608>] r8712_init_drv_sw+0xc8/0x280
[<ffffffff83f3f15f>] r871xu_drv_init+0x20f/0xa80
[<ffffffff834c5a5e>] usb_probe_interface+0x16e/0x420
[<ffffffff82dd0168>] really_probe+0x138/0x3e0
[<ffffffff82dd04ee>] __driver_probe_device+0xce/0x1a0
[<ffffffff82dd05ff>] driver_probe_device+0x2f/0x130
[<ffffffff82dd0824>] __device_attach_driver+0x114/0x170
[<ffffffff82dccdb4>] bus_for_each_drv+0xc4/0x120
[<ffffffff82dcfef5>] __device_attach+0x165/0x260
[<ffffffff82dce617>] bus_probe_device+0xd7/0xe0
[<ffffffff82dcaef5>] device_add+0x935/0xc00
[<ffffffff834c23fc>] usb_set_configuration+0x81c/0xcd0
[<ffffffff834d64e7>] usb_generic_driver_probe+0x87/0xe0
[<ffffffff834c37c1>] usb_probe_device+0x81/0x220
..
// but 1st process is still going, finishing probe
[ 7455.585251][ T8518] usb 1-1: r8712u: finished reading 128 packets
[ 7455.588869][ T8518] usb 1-1: r8712u: CustomerID = 0x0000
[ 7455.589726][ T8518] usb 1-1: r8712u: MAC Address from efuse =
00:e0:4c:87:00:00
[ 7455.591080][ T8518] usb 1-1: r8712u: starting to load fw
[ 7455.591994][ T8518] usb 1-1: r8712u: Loading firmware from
"rtlwifi/rtl8712u.bin"
[ 7455.594094][ T8518] usb 1-1: r8712u: r871xu_drv_init ended well as probe
// probe succeeds, device disconnects and frees all necessary objects
// the very objects at risk as KMEMLEAK sees it.
[ 7455.603027][ T8518] usb 1-1: USB disconnect, device number 8
[ 7455.604359][ T8518] r871xu_dev_remove
[ 7455.655251][ T8518] r8712_free_drv_sw
[ 7455.655910][ T8518] _free_xmit_priv
[1]
Syzbot link: https://syzkaller.appspot.com/bug?extid=83763e624cfec6b462cb
Original repro link:
https://syzkaller.appspot.com/text?tag=ReproC&x=17a7c024e80000
Best regards,
Nikita
On Wed, May 22, 2024 at 06:33:57AM -0700, Nikita Zhandarovich wrote:
> On 5/20/24 10:18, Nam Cao wrote:
> > On Mon, May 20, 2024 at 07:46:41AM -0700, Nikita Zhandarovich wrote:
> >>> 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?
I think you may be right that this is false negative.
I am guessing that kmemleak scans memory for pointers in block of 8-byte.
However, this driver aligns the buffer from kmalloc() to 4 bytes, which is
not necessary because pointers from kmalloc() is at least 8-byte-aligned.
Then more pointers are stored in this 4-byte-aligned buffer. Thus, kmemleak
misses these pointers, and falsely report memory leak.
I never interacted with syzbot before, let's hope it can catch this:
#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
diff --git a/drivers/staging/rtl8712/rtl871x_xmit.c b/drivers/staging/rtl8712/rtl871x_xmit.c
index 6353dbe554d3..408616e9afcf 100644
--- a/drivers/staging/rtl8712/rtl871x_xmit.c
+++ b/drivers/staging/rtl8712/rtl871x_xmit.c
@@ -117,12 +117,9 @@ int _r8712_init_xmit_priv(struct xmit_priv *pxmitpriv,
/*init xmit_buf*/
_init_queue(&pxmitpriv->free_xmitbuf_queue);
_init_queue(&pxmitpriv->pending_xmitbuf_queue);
- pxmitpriv->pallocated_xmitbuf =
- kmalloc(NR_XMITBUFF * sizeof(struct xmit_buf) + 4, GFP_ATOMIC);
- if (!pxmitpriv->pallocated_xmitbuf)
+ pxmitpriv->pxmitbuf = kmalloc(NR_XMITBUFF * sizeof(struct xmit_buf), GFP_ATOMIC);
+ if (!pxmitpriv->pxmitbuf)
goto clean_up_frame_buf;
- pxmitpriv->pxmitbuf = pxmitpriv->pallocated_xmitbuf + 4 -
- ((addr_t)(pxmitpriv->pallocated_xmitbuf) & 3);
pxmitbuf = (struct xmit_buf *)pxmitpriv->pxmitbuf;
for (i = 0; i < NR_XMITBUFF; i++) {
INIT_LIST_HEAD(&pxmitbuf->list);
@@ -165,8 +162,8 @@ int _r8712_init_xmit_priv(struct xmit_priv *pxmitpriv,
for (k = 0; k < 8; k++) /* delete xmit urb's */
usb_free_urb(pxmitbuf->pxmit_urb[k]);
}
- kfree(pxmitpriv->pallocated_xmitbuf);
- pxmitpriv->pallocated_xmitbuf = NULL;
+ kfree(pxmitpriv->pxmitbuf);
+ pxmitpriv->pxmitbuf = NULL;
clean_up_frame_buf:
kfree(pxmitpriv->pallocated_frame_buf);
pxmitpriv->pallocated_frame_buf = NULL;
@@ -193,7 +190,7 @@ void _free_xmit_priv(struct xmit_priv *pxmitpriv)
pxmitbuf++;
}
kfree(pxmitpriv->pallocated_frame_buf);
- kfree(pxmitpriv->pallocated_xmitbuf);
+ kfree(pxmitpriv->pxmitbuf);
free_hwxmits(padapter);
}
diff --git a/drivers/staging/rtl8712/rtl871x_xmit.h b/drivers/staging/rtl8712/rtl871x_xmit.h
index cdcbc87a3cad..784172c385e3 100644
--- a/drivers/staging/rtl8712/rtl871x_xmit.h
+++ b/drivers/staging/rtl8712/rtl871x_xmit.h
@@ -244,7 +244,6 @@ struct xmit_priv {
int cmdseq;
struct __queue free_xmitbuf_queue;
struct __queue pending_xmitbuf_queue;
- u8 *pallocated_xmitbuf;
u8 *pxmitbuf;
uint free_xmitbuf_cnt;
};
Hello,
syzbot has tested the proposed patch and the reproducer did not trigger any issue:
Reported-and-tested-by: [email protected]
Tested on:
commit: 56fb6f92 Merge tag 'drm-next-2024-05-25' of https://gi..
git tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
console output: https://syzkaller.appspot.com/x/log.txt?x=12817cb2980000
kernel config: https://syzkaller.appspot.com/x/.config?x=b43fd1b132bcf5ba
dashboard link: https://syzkaller.appspot.com/bug?extid=83763e624cfec6b462cb
compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
patch: https://syzkaller.appspot.com/x/patch.diff?x=117c460c980000
Note: testing is done by a robot and is best-effort only.