CVE-2022-49201

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ibmvnic: fix race between xmit and reset<br /> <br /> There is a race between reset and the transmit paths that can lead to<br /> ibmvnic_xmit() accessing an scrq after it has been freed in the reset<br /> path. It can result in a crash like:<br /> <br /> Kernel attempted to read user page (0) - exploit attempt? (uid: 0)<br /> BUG: Kernel NULL pointer dereference on read at 0x00000000<br /> Faulting instruction address: 0xc0080000016189f8<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> ...<br /> NIP [c0080000016189f8] ibmvnic_xmit+0x60/0xb60 [ibmvnic]<br /> LR [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280<br /> Call Trace:<br /> [c008000001618f08] ibmvnic_xmit+0x570/0xb60 [ibmvnic] (unreliable)<br /> [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280<br /> [c000000000c9cfcc] sch_direct_xmit+0xec/0x330<br /> [c000000000bfe640] __dev_xmit_skb+0x3a0/0x9d0<br /> [c000000000c00ad4] __dev_queue_xmit+0x394/0x730<br /> [c008000002db813c] __bond_start_xmit+0x254/0x450 [bonding]<br /> [c008000002db8378] bond_start_xmit+0x40/0xc0 [bonding]<br /> [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280<br /> [c000000000c00ca4] __dev_queue_xmit+0x564/0x730<br /> [c000000000cf97e0] neigh_hh_output+0xd0/0x180<br /> [c000000000cfa69c] ip_finish_output2+0x31c/0x5c0<br /> [c000000000cfd244] __ip_queue_xmit+0x194/0x4f0<br /> [c000000000d2a3c4] __tcp_transmit_skb+0x434/0x9b0<br /> [c000000000d2d1e0] __tcp_retransmit_skb+0x1d0/0x6a0<br /> [c000000000d2d984] tcp_retransmit_skb+0x34/0x130<br /> [c000000000d310e8] tcp_retransmit_timer+0x388/0x6d0<br /> [c000000000d315ec] tcp_write_timer_handler+0x1bc/0x330<br /> [c000000000d317bc] tcp_write_timer+0x5c/0x200<br /> [c000000000243270] call_timer_fn+0x50/0x1c0<br /> [c000000000243704] __run_timers.part.0+0x324/0x460<br /> [c000000000243894] run_timer_softirq+0x54/0xa0<br /> [c000000000ea713c] __do_softirq+0x15c/0x3e0<br /> [c000000000166258] __irq_exit_rcu+0x158/0x190<br /> [c000000000166420] irq_exit+0x20/0x40<br /> [c00000000002853c] timer_interrupt+0x14c/0x2b0<br /> [c000000000009a00] decrementer_common_virt+0x210/0x220<br /> --- interrupt: 900 at plpar_hcall_norets_notrace+0x18/0x2c<br /> <br /> The immediate cause of the crash is the access of tx_scrq in the following<br /> snippet during a reset, where the tx_scrq can be either NULL or an address<br /> that will soon be invalid:<br /> <br /> ibmvnic_xmit()<br /> {<br /> ...<br /> tx_scrq = adapter-&gt;tx_scrq[queue_num];<br /> txq = netdev_get_tx_queue(netdev, queue_num);<br /> ind_bufp = &amp;tx_scrq-&gt;ind_buf;<br /> <br /> if (test_bit(0, &amp;adapter-&gt;resetting)) {<br /> ...<br /> }<br /> <br /> But beyond that, the call to ibmvnic_xmit() itself is not safe during a<br /> reset and the reset path attempts to avoid this by stopping the queue in<br /> ibmvnic_cleanup(). However just after the queue was stopped, an in-flight<br /> ibmvnic_complete_tx() could have restarted the queue even as the reset is<br /> progressing.<br /> <br /> Since the queue was restarted we could get a call to ibmvnic_xmit() which<br /> can then access the bad tx_scrq (or other fields).<br /> <br /> We cannot however simply have ibmvnic_complete_tx() check the -&gt;resetting<br /> bit and skip starting the queue. This can race at the "back-end" of a good<br /> reset which just restarted the queue but has not cleared the -&gt;resetting<br /> bit yet. If we skip restarting the queue due to -&gt;resetting being true,<br /> the queue would remain stopped indefinitely potentially leading to transmit<br /> timeouts.<br /> <br /> IOW -&gt;resetting is too broad for this purpose. Instead use a new flag<br /> that indicates whether or not the queues are active. Only the open/<br /> reset paths control when the queues are active. ibmvnic_complete_tx()<br /> and others wake up the queue only if the queue is marked active.<br /> <br /> So we will have:<br /> A. reset/open thread in ibmvnic_cleanup() and __ibmvnic_open()<br /> <br /> -&gt;resetting = true<br /> -&gt;tx_queues_active = false<br /> disable tx queues<br /> ...<br /> -&gt;tx_queues_active = true<br /> start tx queues<br /> <br /> B. Tx interrupt in ibmvnic_complete_tx():<br /> <br /> if (-&gt;tx_queues_active)<br /> netif_wake_subqueue();<br /> <br /> To ensure that -&gt;tx_queues_active and state of the queues are consistent,<br /> we need a lock which:<br /> <br /> - must also be taken in the interrupt path (ibmvnic_complete_tx())<br /> - shared across the multiple<br /> ---truncated---