[syzbot] [can?] memory leak in can_rx_register

2 views
Skip to first unread message

syzbot

unread,
6:11 AM (3 hours ago) 6:11 AM
to linu...@vger.kernel.org, linux-...@vger.kernel.org, m...@pengutronix.de, sock...@hartkopp.net, syzkall...@googlegroups.com
Hello,

syzbot found the following issue on:

HEAD commit: af4e9ef3d784 uaccess: Fix scoped_user_read_access() for 'p..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13a7935a580000
kernel config: https://syzkaller.appspot.com/x/.config?x=2c6ad6fefffa76b1
dashboard link: https://syzkaller.appspot.com/bug?extid=24201717ed2da31b8fae
compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
syz repro: [OBSOLETE] https://syzkaller.appspot.com/x/repro.syz?x=14986d5a580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/70cb2ebe1e6e/disk-af4e9ef3.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/945fea3c8a6d/vmlinux-af4e9ef3.xz
kernel image: https://storage.googleapis.com/syzbot-assets/fa6a6a5cbcc8/bzImage-af4e9ef3.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+242017...@syzkaller.appspotmail.com

BUG: memory leak
unreferenced object 0xffff888127ebfb40 (size 80):
comm "syz.5.22", pid 6143, jiffies 4294942019
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 10 8b fd 08 81 88 ff ff ................
02 00 00 00 ff 07 00 c0 00 00 00 00 00 00 00 00 ................
backtrace (crc 976436cd):
kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
slab_post_alloc_hook mm/slub.c:4520 [inline]
slab_alloc_node mm/slub.c:4844 [inline]
kmem_cache_alloc_noprof+0x372/0x480 mm/slub.c:4851
can_rx_register+0xbf/0x220 net/can/af_can.c:461
isotp_bind+0x470/0x510 net/can/isotp.c:1345
__sys_bind_socket net/socket.c:1874 [inline]
__sys_bind_socket net/socket.c:1866 [inline]
__sys_bind+0x131/0x160 net/socket.c:1905
__do_sys_bind net/socket.c:1910 [inline]
__se_sys_bind net/socket.c:1908 [inline]
__x64_sys_bind+0x1c/0x30 net/socket.c:1908
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f

BUG: memory leak
unreferenced object 0xffff888127ebfaf0 (size 80):
comm "syz.5.22", pid 6143, jiffies 4294942019
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 cb fd 08 81 88 ff ff ................
00 00 00 80 ff ff ff df 00 00 00 00 00 00 00 00 ................
backtrace (crc 4af33172):
kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
slab_post_alloc_hook mm/slub.c:4520 [inline]
slab_alloc_node mm/slub.c:4844 [inline]
kmem_cache_alloc_noprof+0x372/0x480 mm/slub.c:4851
can_rx_register+0xbf/0x220 net/can/af_can.c:461
isotp_bind+0x29f/0x510 net/can/isotp.c:1352
__sys_bind_socket net/socket.c:1874 [inline]
__sys_bind_socket net/socket.c:1866 [inline]
__sys_bind+0x131/0x160 net/socket.c:1905
__do_sys_bind net/socket.c:1910 [inline]
__se_sys_bind net/socket.c:1908 [inline]
__x64_sys_bind+0x1c/0x30 net/socket.c:1908
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f

BUG: memory leak
unreferenced object 0xffff888127d994b0 (size 80):
comm "syz.6.23", pid 6176, jiffies 4294942079
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 10 8b a8 13 81 88 ff ff ................
02 00 00 00 ff 07 00 c0 00 00 00 00 00 00 00 00 ................
backtrace (crc 179b079f):
kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
slab_post_alloc_hook mm/slub.c:4520 [inline]
slab_alloc_node mm/slub.c:4844 [inline]
kmem_cache_alloc_noprof+0x372/0x480 mm/slub.c:4851
can_rx_register+0xbf/0x220 net/can/af_can.c:461
isotp_bind+0x470/0x510 net/can/isotp.c:1345
__sys_bind_socket net/socket.c:1874 [inline]
__sys_bind_socket net/socket.c:1866 [inline]
__sys_bind+0x131/0x160 net/socket.c:1905
__do_sys_bind net/socket.c:1910 [inline]
__se_sys_bind net/socket.c:1908 [inline]
__x64_sys_bind+0x1c/0x30 net/socket.c:1908
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f

BUG: memory leak
unreferenced object 0xffff888127d99460 (size 80):
comm "syz.6.23", pid 6176, jiffies 4294942079
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 cb a8 13 81 88 ff ff ................
00 00 00 80 ff ff ff df 00 00 00 00 00 00 00 00 ................
backtrace (crc ca0c0020):
kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
slab_post_alloc_hook mm/slub.c:4520 [inline]
slab_alloc_node mm/slub.c:4844 [inline]
kmem_cache_alloc_noprof+0x372/0x480 mm/slub.c:4851
can_rx_register+0xbf/0x220 net/can/af_can.c:461
isotp_bind+0x29f/0x510 net/can/isotp.c:1352
__sys_bind_socket net/socket.c:1874 [inline]
__sys_bind_socket net/socket.c:1866 [inline]
__sys_bind+0x131/0x160 net/socket.c:1905
__do_sys_bind net/socket.c:1910 [inline]
__se_sys_bind net/socket.c:1908 [inline]
__x64_sys_bind+0x1c/0x30 net/socket.c:1908
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f

connection error: failed to recv *flatrpc.ExecutorMessageRawT: EOF


---
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 syzk...@googlegroups.com.

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

Oliver Hartkopp

unread,
8:48 AM (20 minutes ago) 8:48 AM
to syzbot, linu...@vger.kernel.org, linux-...@vger.kernel.org, m...@pengutronix.de, syzkall...@googlegroups.com
Hi,

I don't see any CAN netdevice name in the logs.

So it is likely some bonding/teaming magic again, which should be fixed
by "bonding: refuse to enslave CAN devices"

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8ba68464e4787b6a7ec938826e16124df20fd23d

Best regards,
Oliver
Reply all
Reply to author
Forward
0 new messages