| 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: <CANn89iKi6tyaM_0HPu4SsCE1M8tzXB_VvkEyz-27PM9u-1dMVQ@mail.gmail.com> Date: Thu, 22 Jan 2026 09:07:52 +0100 From: Eric Dumazet <edumazet@...gle.com> To: 白烁冉 <baishuoran@...eu.edu.cn> Cc: "David S. Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, Kun Hu <huk23@...udan.edu.cn>, Jiaji Qin <jjtan24@...udan.edu.cn>, Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org, syzkaller@...glegroups.com, linux-kernel@...r.kernel.org Subject: Re: hung task in rtnl_newlink On Thu, Jan 22, 2026 at 8:56 AM 白烁冉 <baishuoran@...eu.edu.cn> wrote: > > Dear Maintainers, > > > When using our customized Syzkaller to fuzz the latest Linux kernel, the following crash was triggered. > > > HEAD commit: 6537cfb395f352782918d8ee7b7f10ba2cc3cbf2 > git tree: upstream > Output:https:https://github.com/pghk13/Kernel-Bug/blob/main/0702_6.14/9%20hung%20task%20in%20rtnl_newlink/report9.txt > Kernel config: https://github.com/pghk13/Kernel-Bug/blob/main/0219_6.13rc7_todo/config.txt > C reproducer:https://github.com/pghk13/Kernel-Bug/blob/main/0702_6.14/9%20hung%20task%20in%20rtnl_newlink/9repro.txt > Syzlang reproducer: https://github.com/pghk13/Kernel-Bug/blob/main/0702_6.14/9%20hung%20task%20in%20rtnl_newlink/9repro.c > > The hung-task is primarily associated with the linkwatch workqueue callback. Specifically, linkwatch_event() processes batches of devices while holding RTNL (rtnl_lock()), during which it repeatedly invokes linkwatch_do_dev() and further calls paths such as dev_activate(), dev_deactivate(), and netdev_state_change(), which may involve relatively time-consuming or blocking operations (link_watch.c:285–287, 194–254, 166–187). At the same time, messages sent from userspace via sendmsg enter the kernel synchronously through netlink_unicast_kernel() in af_netlink.c (af_netlink.c:1312) and are handled in the protocol callback invoked from netlink_rcv_skb() (af_netlink.c:2533). As a result, when RTNL is held by linkwatch for an extended period, a large number of rtnetlink requests may block while attempting to acquire RTNL, enter the D state, and eventually trigger hung-task reports. > We have reproduced this issue several times on 6.19-rc4 again. > > > If you fix this issue, please add the following tag to the commit: > Reported-by: Kun Hu <huk23@...udan.edu.cn>, Jiaji Qin <jjtan24@...udan.edu.cn>, Shuoran Bai <baishuoran@...eu.edu.cn> > Note : This problem has been reported many times by syzbot. Also, the following trace is not really helpful. You should use scripts/decode_stacktrace.sh on it. >> > [ 579.240159][ T46] </TASK> > [ 579.241133][ T46] INFO: task syz-executor:10690 blocked for more than 183 seconds. > [ 579.243486][ T46] Not tainted 6.19.0-rc4 #1 > [ 579.245045][ T46] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > [ 579.247776][ T46] task:syz-executor state:D stack:11296 pid:10690 tgid:10690 ppid:1 task_flags:0x400140 flags:0x00080002 > [ 579.251394][ T46] Call Trace: > [ 579.252443][ T46] <TASK> > [ 579.253371][ T46] __schedule+0xe62/0x1fa0 > [ 579.254791][ T46] ? srso_alias_return_thunk+0x5/0xfbef5 > [ 579.256666][ T46] ? schedule+0xb6/0xe0 > [ 579.258063][ T46] schedule+0x34/0xe0 > [ 579.259368][ T46] schedule_preempt_disabled+0xf/0x20 > [ 579.261101][ T46] __mutex_lock+0x810/0x1240 > [ 579.262603][ T46] ? __sanitizer_cov_trace_pc+0x1c/0x50 > [ 579.264341][ T46] ? srso_alias_return_thunk+0x5/0xfbef5 > [ 579.266153][ T46] ? rtnl_newlink+0x4cb/0x760 > [ 579.267639][ T46] ? srso_alias_return_thunk+0x5/0xfbef5 > [ 579.269590][ T46] ? rtnl_newlink+0x4cb/0x760 > [ 579.271070][ T46] rtnl_newlink+0x4cb/0x760 > [ 579.272516][ T46] ? srso_alias_return_thunk+0x5/0xfbef5 > [ 579.274280][ T46] ? srso_alias_return_thunk+0x5/0xfbef5 > [ 579.276178][ T46] ? srso_alias_return_thunk+0x5/0xfbef5 > [ 579.277919][ T46] ? __pfx_rtnl_newlink+0x10/0x10 > [ 579.279488][ T46] rtnetlink_rcv_msg+0x6af/0xae0 > [ 579.281023][ T46] ? srso_alias_return_thunk+0x5/0xfbef5 > [ 579.282754][ T46] ? __sanitizer_cov_trace_pc+0x1c/0x50 > [ 579.284506][ T46] ? srso_alias_return_thunk+0x5/0xfbef5 > [ 579.286346][ T46] ? ref_tracker_free+0x157/0x2e0 > [ 579.287958][ T46] ? srso_alias_return_thunk+0x5/0xfbef5 > [ 579.289777][ T46] netlink_rcv_skb+0x7d/0x1c0 > [ 579.291270][ T46] ? __pfx_rtnetlink_rcv_msg+0x10/0x10 > [ 579.293003][ T46] netlink_unicast+0x2bc/0x3d0 > [ 579.294555][ T46] ? srso_alias_return_thunk+0x5/0xfbef5 > [ 579.296425][ T46] netlink_sendmsg+0x340/0x690 > [ 579.298010][ T46] __sock_sendmsg+0x11b/0x130 > [ 579.299505][ T46] __sys_sendto+0x18d/0x210 > [ 579.301045][ T46] ? srso_alias_return_thunk+0x5/0xfbef5 > [ 579.302777][ T46] ? xfd_validate_state+0x3b/0xe0 > [ 579.304392][ T46] ? srso_alias_return_thunk+0x5/0xfbef5 > [ 579.306225][ T46] ? __sanitizer_cov_trace_pc+0x1c/0x50 > [ 579.307979][ T46] ? srso_alias_return_thunk+0x5/0xfbef5 > [ 579.309720][ T46] ? write_comp_data+0x29/0x80 > [ 579.311228][ T46] __x64_sys_sendto+0x26/0x30 > [ 579.312726][ T46] do_syscall_64+0xc3/0x11e0 > [ 579.314233][ T46] entry_SYSCALL_64_after_hwframe+0x77/0x7f > [ 579.316176][ T46] RIP: 0033:0x7f947bd1ee04 > [ 579.317561][ T46] RSP: 002b:00007ffca283d060 EFLAGS: 00000293 ORIG_RAX: 000000000000002c > [ 579.320127][ T46] RAX: ffffffffffffffda RBX: 00007f947cad4620 RCX: 00007f947bd1ee04 > [ 579.322503][ T46] RDX: 000000000000002c RSI: 00007f947cad4670 RDI: 0000000000000003 > [ 579.324925][ T46] RBP: 0000000000000000 R08: 00007ffca283d0bc R09: 000000000000000c > [ 579.327410][ T46] R10: 0000000000000000 R11: 0000000000000293 R12: 00000000000000 > > thanks, > Kun Hu
Powered by blists - more mailing lists