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