{
  "cveId": "CVE-2022-49201",
  "url": "https://patchblox.com/security/cve/CVE-2022-49201",
  "summary": "CVE-2022-49201 is fixed in linux on 1 platform, first by DEBIAN-CVE-2022-49201, released February 26, 2025. It is not reported as exploited. Patch Radar priority: Routine.",
  "title": "linux: In the Linux kernel, the following vulnerability has been resolved:  ibmvnic: fix race between xmit and reset  There...",
  "description": "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\u002B0x60/0xb60 [ibmvnic] \tLR [c000000000c0046c] dev_hard_start_xmit\u002B0x11c/0x280 \tCall Trace: \t[c008000001618f08] ibmvnic_xmit\u002B0x570/0xb60 [ibmvnic] (unreliable) \t[c000000000c0046c] dev_hard_start_xmit\u002B0x11c/0x280 \t[c000000000c9cfcc] sch_direct_xmit\u002B0xec/0x330 \t[c000000000bfe640] __dev_xmit_skb\u002B0x3a0/0x9d0 \t[c000000000c00ad4] __dev_queue_xmit\u002B0x394/0x730 \t[c008000002db813c] __bond_start_xmit\u002B0x254/0x450 [bonding] \t[c008000002db8378] bond_start_xmit\u002B0x40/0xc0 [bonding] \t[c000000000c0046c] dev_hard_start_xmit\u002B0x11c/0x280 \t[c000000000c00ca4] __dev_queue_xmit\u002B0x564/0x730 \t[c000000000cf97e0] neigh_hh_output\u002B0xd0/0x180 \t[c000000000cfa69c] ip_finish_output2\u002B0x31c/0x5c0 \t[c000000000cfd244] __ip_queue_xmit\u002B0x194/0x4f0 \t[c000000000d2a3c4] __tcp_transmit_skb\u002B0x434/0x9b0 \t[c000000000d2d1e0] __tcp_retransmit_skb\u002B0x1d0/0x6a0 \t[c000000000d2d984] tcp_retransmit_skb\u002B0x34/0x130 \t[c000000000d310e8] tcp_retransmit_timer\u002B0x388/0x6d0 \t[c000000000d315ec] tcp_write_timer_handler\u002B0x1bc/0x330 \t[c000000000d317bc] tcp_write_timer\u002B0x5c/0x200 \t[c000000000243270] call_timer_fn\u002B0x50/0x1c0 \t[c000000000243704] __run_timers.part.0\u002B0x324/0x460 \t[c000000000243894] run_timer_softirq\u002B0x54/0xa0 \t[c000000000ea713c] __do_softirq\u002B0x15c/0x3e0 \t[c000000000166258] __irq_exit_rcu\u002B0x158/0x190 \t[c000000000166420] irq_exit\u002B0x20/0x40 \t[c00000000002853c] timer_interrupt\u002B0x14c/0x2b0 \t[c000000000009a00] decrementer_common_virt\u002B0x210/0x220 \t--- interrupt: 900 at plpar_hcall_norets_notrace\u002B0x18/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 = \u0026tx_scrq-\u003Eind_buf;  \t\tif (test_bit(0, \u0026adapter-\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 \u0022back-end\u0022 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---",
  "published": "2025-02-26T07:00:57Z",
  "severity": "medium",
  "cvss": 4.7,
  "cvssVector": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
  "epss": 0.00501,
  "epssPercentile": 0.43139,
  "priority": "Routine",
  "priorityTier": 4,
  "exploited": false,
  "vendorExploited": false,
  "disclosed": false,
  "fixes": [
    {
      "platform": "linux",
      "product": "linux",
      "release": "Debian 12.15 (bookworm)",
      "fixedVersion": "5.17.3-1",
      "fix": "DEBIAN-CVE-2022-49201",
      "url": "https://patchblox.com/security/fix/linux/debian-cve-2022-49201",
      "released": "2025-02-26T07:00:57Z"
    },
    {
      "platform": "linux",
      "product": "linux",
      "release": "Debian 13.5 (trixie)",
      "fixedVersion": "5.17.3-1",
      "fix": "DEBIAN-CVE-2022-49201",
      "url": "https://patchblox.com/security/fix/linux/debian-cve-2022-49201",
      "released": "2025-02-26T07:00:57Z"
    },
    {
      "platform": "linux",
      "product": "linux",
      "release": "Debian 14",
      "fixedVersion": "5.17.3-1",
      "fix": "DEBIAN-CVE-2022-49201",
      "url": "https://patchblox.com/security/fix/linux/debian-cve-2022-49201",
      "released": "2025-02-26T07:00:57Z"
    }
  ],
  "noFixYet": [],
  "dataAsOf": "2026-11-08T00:53:09Z",
  "attribution": {
    "text": "Data: Patchblox Patch Radar",
    "url": "https://patchblox.com/security/patch-radar",
    "terms": "https://patchblox.com/security/patch-radar/use-the-data"
  }
}