In the Linux kernel, the following vulnerability has been resolved:[EOL][EOL]netlink: fix potential deadlock in netlink_set_err()[EOL][EOL]syzbot reported a possible deadlock in netlink_set_err() [1][EOL][EOL]A similar issue was fixed in commit 1d482e666b8e ("netlink: disable IRQs[EOL]for netlink_lock_table()") in netlink_lock_table()[EOL][EOL]This patch adds IRQ safety to netlink_set_err() and __netlink_diag_dump()[EOL]which were not covered by cited commit.[EOL][EOL][1][EOL][EOL]WARNING: possible irq lock inversion dependency detected[EOL]6.4.0-rc6-syzkaller-00240-g4e9f0ec38852 #0 Not tainted[EOL][EOL]syz-executor.2/23011 just changed the state of lock:[EOL]ffffffff8e1a7a58 (nl_table_lock){.+.?}-{2:2}, at: netlink_set_err+0x2e/0x3a0 net/netlink/af_netlink.c:1612[EOL]but this lock was taken by another, SOFTIRQ-safe lock in the past:[EOL] (&local->queue_stop_reason_lock){..-.}-{2:2}[EOL][EOL]and interrupts could create inverse lock ordering between them.[EOL][EOL]other info that might help us debug this:[EOL] Possible interrupt unsafe locking scenario:[EOL][EOL] CPU0 CPU1[EOL] ---- ----[EOL] lock(nl_table_lock);[EOL] local_irq_disable();[EOL] lock(&local->queue_stop_reason_lock);[EOL] lock(nl_table_lock);[EOL] <Interrupt>[EOL] lock(&local->queue_stop_reason_lock);[EOL][EOL] *** DEADLOCK ***
