CVE-2022-49201: Vulnerability in Linux Linux

Severity: highType: vulnerabilityCVE-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---

AI Analysis

Technical Summary

CVE-2022-49201 is a race condition vulnerability in the Linux kernel's ibmvnic network driver, which is used primarily on IBM Power Systems hardware to provide virtualized network interface functionality. The vulnerability arises from a race between the transmit (xmit) path and the reset path of the ibmvnic driver. Specifically, during a reset operation, the driver frees certain transmit queue structures (tx_scrq), but due to a timing issue, the transmit function ibmvnic_xmit() may still access these freed structures. This results in a NULL pointer dereference or access to invalid memory, causing a kernel crash (kernel oops). The root cause is that the reset path stops the transmit queues, but an in-flight transmit completion (ibmvnic_complete_tx()) can restart the queues before the reset completes, leading to unsafe access to freed memory. The fix involves introducing a new flag (tx_queues_active) to more precisely control queue activity state, separate from the broader resetting flag, and protecting queue state changes with a lock that is also taken in the interrupt context. This prevents the transmit path from accessing freed memory during reset sequences. The vulnerability can cause system instability or denial of service (DoS) due to kernel crashes. There is no indication that this vulnerability allows privilege escalation or remote code execution. No known exploits are reported in the wild as of the publication date. The affected versions correspond to Linux kernel commits prior to the patch, primarily impacting IBM Power Systems running Linux with the ibmvnic driver.

Potential Impact

For European organizations utilizing IBM Power Systems running Linux with the ibmvnic driver, this vulnerability poses a risk of kernel crashes leading to denial of service. Such systems are often deployed in enterprise data centers for critical workloads, including financial services, telecommunications, and government infrastructure. A kernel crash can cause service interruptions, data processing delays, and potential loss of availability for critical applications. While the vulnerability does not appear to allow direct code execution or data compromise, the resulting instability can impact operational continuity and require emergency system reboots or maintenance. Organizations with high availability requirements or those running virtualized environments on IBM Power Systems should be particularly cautious. The lack of known exploits reduces immediate risk, but the vulnerability's presence in kernel code means that attackers with local access or the ability to trigger network traffic on affected interfaces could potentially cause denial of service conditions. This could be leveraged as part of a broader attack or disruption campaign. Given the specialized nature of the ibmvnic driver, the impact is limited to environments using this hardware and driver combination.

Mitigation Recommendations

1. Apply the official Linux kernel patches that address CVE-2022-49201 as soon as they become available from trusted Linux distributions or kernel maintainers. 2. For organizations using IBM Power Systems, coordinate with hardware and OS vendors to ensure updated kernel versions with the fix are deployed. 3. Implement strict access controls and monitoring on systems running the ibmvnic driver to detect unusual kernel oops or crashes that may indicate exploitation attempts. 4. Limit local user access and restrict network traffic to trusted sources to reduce the risk of triggering the race condition. 5. Consider implementing kernel crash dump and analysis tools to quickly diagnose and respond to any crashes related to this vulnerability. 6. In virtualized environments, isolate workloads and apply network segmentation to minimize the impact of potential DoS conditions. 7. Maintain up-to-date backups and disaster recovery plans to mitigate operational impact from unexpected system crashes.