CVE-2023-53022

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: enetc: avoid deadlock in enetc_tx_onestep_tstamp()<br /> <br /> This lockdep splat says it better than I could:<br /> <br /> ================================<br /> WARNING: inconsistent lock state<br /> 6.2.0-rc2-07010-ga9b9500ffaac-dirty #967 Not tainted<br /> --------------------------------<br /> inconsistent {IN-SOFTIRQ-W} -&gt; {SOFTIRQ-ON-W} usage.<br /> kworker/1:3/179 [HC0[0]:SC0[0]:HE1:SE1] takes:<br /> ffff3ec4036ce098 (_xmit_ETHER#2){+.?.}-{3:3}, at: netif_freeze_queues+0x5c/0xc0<br /> {IN-SOFTIRQ-W} state was registered at:<br /> _raw_spin_lock+0x5c/0xc0<br /> sch_direct_xmit+0x148/0x37c<br /> __dev_queue_xmit+0x528/0x111c<br /> ip6_finish_output2+0x5ec/0xb7c<br /> ip6_finish_output+0x240/0x3f0<br /> ip6_output+0x78/0x360<br /> ndisc_send_skb+0x33c/0x85c<br /> ndisc_send_rs+0x54/0x12c<br /> addrconf_rs_timer+0x154/0x260<br /> call_timer_fn+0xb8/0x3a0<br /> __run_timers.part.0+0x214/0x26c<br /> run_timer_softirq+0x3c/0x74<br /> __do_softirq+0x14c/0x5d8<br /> ____do_softirq+0x10/0x20<br /> call_on_irq_stack+0x2c/0x5c<br /> do_softirq_own_stack+0x1c/0x30<br /> __irq_exit_rcu+0x168/0x1a0<br /> irq_exit_rcu+0x10/0x40<br /> el1_interrupt+0x38/0x64<br /> irq event stamp: 7825<br /> hardirqs last enabled at (7825): [] exit_to_kernel_mode+0x34/0x130<br /> hardirqs last disabled at (7823): [] __do_softirq+0x550/0x5d8<br /> softirqs last enabled at (7824): [] __do_softirq+0x46c/0x5d8<br /> softirqs last disabled at (7811): [] ____do_softirq+0x10/0x20<br /> <br /> other info that might help us debug this:<br /> Possible unsafe locking scenario:<br /> <br /> CPU0<br /> ----<br /> lock(_xmit_ETHER#2);<br /> <br /> lock(_xmit_ETHER#2);<br /> <br /> *** DEADLOCK ***<br /> <br /> 3 locks held by kworker/1:3/179:<br /> #0: ffff3ec400004748 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x1f4/0x6c0<br /> #1: ffff80000a0bbdc8 ((work_completion)(&amp;priv-&gt;tx_onestep_tstamp)){+.+.}-{0:0}, at: process_one_work+0x1f4/0x6c0<br /> #2: ffff3ec4036cd438 (&amp;dev-&gt;tx_global_lock){+.+.}-{3:3}, at: netif_tx_lock+0x1c/0x34<br /> <br /> Workqueue: events enetc_tx_onestep_tstamp<br /> Call trace:<br /> print_usage_bug.part.0+0x208/0x22c<br /> mark_lock+0x7f0/0x8b0<br /> __lock_acquire+0x7c4/0x1ce0<br /> lock_acquire.part.0+0xe0/0x220<br /> lock_acquire+0x68/0x84<br /> _raw_spin_lock+0x5c/0xc0<br /> netif_freeze_queues+0x5c/0xc0<br /> netif_tx_lock+0x24/0x34<br /> enetc_tx_onestep_tstamp+0x20/0x100<br /> process_one_work+0x28c/0x6c0<br /> worker_thread+0x74/0x450<br /> kthread+0x118/0x11c<br /> <br /> but I&amp;#39;ll say it anyway: the enetc_tx_onestep_tstamp() work item runs in<br /> process context, therefore with softirqs enabled (i.o.w., it can be<br /> interrupted by a softirq). If we hold the netif_tx_lock() when there is<br /> an interrupt, and the NET_TX softirq then gets scheduled, this will take<br /> the netif_tx_lock() a second time and deadlock the kernel.<br /> <br /> To solve this, use netif_tx_lock_bh(), which blocks softirqs from<br /> running.