{"id":"DEBIAN-CVE-2022-49201","details":"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:  \tKernel attempted to read user page (0) - exploit attempt? (uid: 0) \tBUG: Kernel NULL pointer dereference on read at 0x00000000 \tFaulting instruction address: 0xc0080000016189f8 \tOops: Kernel access of bad area, sig: 11 [#1] \t... \tNIP [c0080000016189f8] ibmvnic_xmit+0x60/0xb60 [ibmvnic] \tLR [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280 \tCall Trace: \t[c008000001618f08] ibmvnic_xmit+0x570/0xb60 [ibmvnic] (unreliable) \t[c000000000c0046c] dev_hard_start_xmit+0x11c/0x280 \t[c000000000c9cfcc] sch_direct_xmit+0xec/0x330 \t[c000000000bfe640] __dev_xmit_skb+0x3a0/0x9d0 \t[c000000000c00ad4] __dev_queue_xmit+0x394/0x730 \t[c008000002db813c] __bond_start_xmit+0x254/0x450 [bonding] \t[c008000002db8378] bond_start_xmit+0x40/0xc0 [bonding] \t[c000000000c0046c] dev_hard_start_xmit+0x11c/0x280 \t[c000000000c00ca4] __dev_queue_xmit+0x564/0x730 \t[c000000000cf97e0] neigh_hh_output+0xd0/0x180 \t[c000000000cfa69c] ip_finish_output2+0x31c/0x5c0 \t[c000000000cfd244] __ip_queue_xmit+0x194/0x4f0 \t[c000000000d2a3c4] __tcp_transmit_skb+0x434/0x9b0 \t[c000000000d2d1e0] __tcp_retransmit_skb+0x1d0/0x6a0 \t[c000000000d2d984] tcp_retransmit_skb+0x34/0x130 \t[c000000000d310e8] tcp_retransmit_timer+0x388/0x6d0 \t[c000000000d315ec] tcp_write_timer_handler+0x1bc/0x330 \t[c000000000d317bc] tcp_write_timer+0x5c/0x200 \t[c000000000243270] call_timer_fn+0x50/0x1c0 \t[c000000000243704] __run_timers.part.0+0x324/0x460 \t[c000000000243894] run_timer_softirq+0x54/0xa0 \t[c000000000ea713c] __do_softirq+0x15c/0x3e0 \t[c000000000166258] __irq_exit_rcu+0x158/0x190 \t[c000000000166420] irq_exit+0x20/0x40 \t[c00000000002853c] timer_interrupt+0x14c/0x2b0 \t[c000000000009a00] decrementer_common_virt+0x210/0x220 \t--- 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:  \tibmvnic_xmit() \t{ \t\t... \t\ttx_scrq = adapter-\u003etx_scrq[queue_num]; \t\ttxq = netdev_get_tx_queue(netdev, queue_num); \t\tind_bufp = &tx_scrq-\u003eind_buf;  \t\tif (test_bit(0, &adapter-\u003eresetting)) { \t\t... \t}  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 -\u003eresetting 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 -\u003eresetting bit yet. If we skip restarting the queue due to -\u003eresetting being true, the queue would remain stopped indefinitely potentially leading to transmit timeouts.  IOW -\u003eresetting 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: \tA. reset/open thread in ibmvnic_cleanup() and __ibmvnic_open()  \t\t-\u003eresetting = true \t\t-\u003etx_queues_active = false \t\tdisable tx queues \t\t... \t\t-\u003etx_queues_active = true \t\tstart tx queues  \tB. Tx interrupt in ibmvnic_complete_tx():  \t\tif (-\u003etx_queues_active) \t\t\tnetif_wake_subqueue();  To ensure that -\u003etx_queues_active and state of the queues are consistent, we need a lock which:  \t- must also be taken in the interrupt path (ibmvnic_complete_tx()) \t- shared across the multiple ---truncated---","modified":"2026-09-01T16:05:30.264177128Z","published":"2025-02-26T07:00:57.160Z","upstream":["CVE-2022-49201"],"references":[{"type":"ADVISORY","url":"https://security-tracker.debian.org/tracker/CVE-2022-49201"}],"affected":[{"package":{"name":"linux","ecosystem":"Debian:12","purl":"pkg:deb/debian/linux?arch=source&distro=bookworm"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.17.3-1"}]}],"ecosystem_specific":{"urgency":"not yet assigned"},"database_specific":{"source":"https://storage.googleapis.com/osv-test-debian-osv/debian-cve-osv/DEBIAN-CVE-2022-49201.json"}},{"package":{"name":"linux","ecosystem":"Debian:13","purl":"pkg:deb/debian/linux?arch=source&distro=trixie"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.17.3-1"}]}],"ecosystem_specific":{"urgency":"not yet assigned"},"database_specific":{"source":"https://storage.googleapis.com/osv-test-debian-osv/debian-cve-osv/DEBIAN-CVE-2022-49201.json"}},{"package":{"name":"linux","ecosystem":"Debian:14","purl":"pkg:deb/debian/linux?arch=source&distro=forky"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.17.3-1"}]}],"ecosystem_specific":{"urgency":"not yet assigned"},"database_specific":{"source":"https://storage.googleapis.com/osv-test-debian-osv/debian-cve-osv/DEBIAN-CVE-2022-49201.json"}}],"schema_version":"1.9.0","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H"}]}