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
| ||
|
Message-ID: <000000000000ccd19405d7b6e687@google.com> Date: Thu, 10 Feb 2022 20:57:19 -0800 From: syzbot <syzbot+787eccd42a00a400e647@...kaller.appspotmail.com> To: claudiajkang@...il.com, davem@...emloft.net, ennoerlangen@...il.com, george.mccollister@...il.com, kuba@...nel.org, linux-kernel@...r.kernel.org, linux-next@...r.kernel.org, marco.wenzel@...berle.de, netdev@...r.kernel.org, olteanv@...il.com, sfr@...b.auug.org.au, syzkaller-bugs@...glegroups.com Subject: [syzbot] linux-next test error: WARNING: suspicious RCU usage in hsr_node_get_first Hello, syzbot found the following issue on: HEAD commit: 554f92dbda16 Add linux-next specific files for 20220208 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=13655472700000 kernel config: https://syzkaller.appspot.com/x/.config?x=540b1094b49a74bd dashboard link: https://syzkaller.appspot.com/bug?extid=787eccd42a00a400e647 compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+787eccd42a00a400e647@...kaller.appspotmail.com batman_adv: batadv0: The MTU of interface batadv_slave_1 is too small (1500) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1560 would solve the problem. batman_adv: batadv0: Not using interface batadv_slave_1 (retrying later): interface not active ============================= WARNING: suspicious RCU usage 5.17.0-rc3-next-20220208-syzkaller #0 Not tainted ----------------------------- net/hsr/hsr_framereg.c:34 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 2 locks held by syz-executor.0/3596: #0: ffffffff8d3357e8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_lock net/core/rtnetlink.c:72 [inline] #0: ffffffff8d3357e8 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x3be/0xb80 net/core/rtnetlink.c:5591 #1: ffff88807ec9d5f0 (&hsr->list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:359 [inline] #1: ffff88807ec9d5f0 (&hsr->list_lock){+...}-{2:2}, at: hsr_create_self_node+0x225/0x650 net/hsr/hsr_framereg.c:108 stack backtrace: CPU: 1 PID: 3596 Comm: syz-executor.0 Not tainted 5.17.0-rc3-next-20220208-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 hsr_node_get_first+0x9b/0xb0 net/hsr/hsr_framereg.c:34 hsr_create_self_node+0x22d/0x650 net/hsr/hsr_framereg.c:109 hsr_dev_finalize+0x2c1/0x7d0 net/hsr/hsr_device.c:514 hsr_newlink+0x315/0x730 net/hsr/hsr_netlink.c:102 __rtnl_newlink+0x107c/0x1760 net/core/rtnetlink.c:3481 rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3529 rtnetlink_rcv_msg+0x413/0xb80 net/core/rtnetlink.c:5594 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2494 netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline] netlink_unicast+0x539/0x7e0 net/netlink/af_netlink.c:1343 netlink_sendmsg+0x904/0xe00 net/netlink/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:705 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:725 __sys_sendto+0x21c/0x320 net/socket.c:2040 __do_sys_sendto net/socket.c:2052 [inline] __se_sys_sendto net/socket.c:2048 [inline] __x64_sys_sendto+0xdd/0x1b0 net/socket.c:2048 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f3148504e1c Code: fa fa ff ff 44 8b 4c 24 2c 4c 8b 44 24 20 89 c5 44 8b 54 24 28 48 8b 54 24 18 b8 2c 00 00 00 48 8b 74 24 10 8b 7c 24 08 0f 05 <48> 3d 00 f0 ff ff 77 34 89 ef 48 89 44 24 08 e8 20 fb ff ff 48 8b RSP: 002b:00007ffeab5f2ab0 EFLAGS: 00000293 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f314959d320 RCX: 00007f3148504e1c RDX: 0000000000000048 RSI: 00007f314959d370 RDI: 0000000000000003 RBP: 0000000000000000 R08: 00007ffeab5f2b04 R09: 000000000000000c R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00007f314959d370 R14: 0000000000000003 R15: 0000000000000000 </TASK> device hsr_slave_0 entered promiscuous mode device hsr_slave_1 entered promiscuous mode netdevsim netdevsim0 netdevsim0: renamed from eth0 netdevsim netdevsim0 netdevsim1: renamed from eth1 netdevsim netdevsim0 netdevsim2: renamed from eth2 netdevsim netdevsim0 netdevsim3: renamed from eth3 bridge0: port 2(bridge_slave_1) entered blocking state bridge0: port 2(bridge_slave_1) entered forwarding state bridge0: port 1(bridge_slave_0) entered blocking state bridge0: port 1(bridge_slave_0) entered forwarding state 8021q: adding VLAN 0 to HW filter on device bond0 8021q: adding VLAN 0 to HW filter on device team0 IPv6: ADDRCONF(NETDEV_CHANGE): hsr0: link becomes ready 8021q: adding VLAN 0 to HW filter on device batadv0 device veth0_vlan entered promiscuous mode device veth1_vlan entered promiscuous mode device veth0_macvtap entered promiscuous mode device veth1_macvtap entered promiscuous mode batman_adv: batadv0: Interface activated: batadv_slave_0 batman_adv: batadv0: Interface activated: batadv_slave_1 netdevsim netdevsim0 netdevsim0: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim0 netdevsim1: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim0 netdevsim2: set [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim0 netdevsim3: set [1, 0] type 2 family 0 port 6081 - 0 syz-executor.0 (3596) used greatest stack depth: 22424 bytes left --- 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 syzkaller@...glegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
Powered by blists - more mailing lists