UBUNTU-CVE-2022-49201: Null Pointer Dereference

Q: Which systems are most likely to be exposed?

Systems using the ibmvnic network driver are implicated. The affected Ubuntu kernel package families listed are linux, linux-aws, linux-azure, linux-gcp, linux-gke, linux-hwe-edge, linux-ibm, and linux-kvm.

Q: What access and conditions are required for exploitation?

The supplied CVSS vector indicates local access, low privileges, no user interaction, and high attack complexity. The failure requires a race between the transmit path and a reset path, causing ibmvnic_xmit() to access an SCRQ after reset has freed it.

Q: How might an affected system behave?

The documented impact is a kernel crash caused by a NULL pointer dereference during transmission. Crash output may identify ibmvnic_xmit in the call trace and include messages such as "Kernel NULL pointer dereference" or "Kernel access of bad area."}]}

Published Feb 26, 2025

Updated

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 ibmvnicxmit() 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] ibmvnicxmit+0x60/0xb60 [ibmvnic] LR [c000000000c0046c] devhardstartxmit+0x11c/0x280 Call Trace: [c008000001618f08] ibmvnicxmit+0x570/0xb60 [ibmvnic] (unreliable) [c000000000c0046c] devhardstartxmit+0x11c/0x280 [c000000000c9cfcc] schdirectxmit+0xec/0x330 [c000000000bfe640] devxmitskb+0x3a0/0x9d0 [c000000000c00ad4] devqueuexmit+0x394/0x730 [c008000002db813c] bondstartxmit+0x254/0x450 [bonding] [c008000002db8378] bondstartxmit+0x40/0xc0 [bonding] [c000000000c0046c] devhardstartxmit+0x11c/0x280 [c000000000c00ca4] devqueuexmit+0x564/0x730 [c000000000cf97e0] neighhhoutput+0xd0/0x180 [c000000000cfa69c] ipfinishoutput2+0x31c/0x5c0 [c000000000cfd244] ipqueuexmit+0x194/0x4f0 [c000000000d2a3c4] tcptransmitskb+0x434/0x9b0 [c000000000d2d1e0] tcpretransmitskb+0x1d0/0x6a0 [c000000000d2d984] tcpretransmitskb+0x34/0x130 [c000000000d310e8] tcpretransmittimer+0x388/0x6d0 [c000000000d315ec] tcpwritetimerhandler+0x1bc/0x330 [c000000000d317bc] tcpwritetimer+0x5c/0x200 [c000000000243270] calltimerfn+0x50/0x1c0 [c000000000243704] runtimers.part.0+0x324/0x460 [c000000000243894] runtimersoftirq+0x54/0xa0 [c000000000ea713c] dosoftirq+0x15c/0x3e0 [c000000000166258] irqexitrcu+0x158/0x190 [c000000000166420] irqexit+0x20/0x40 [c00000000002853c] timerinterrupt+0x14c/0x2b0 [c000000000009a00] decrementercommonvirt+0x210/0x220 --- interrupt: 900 at plparhcallnoretsnotrace+0x18/0x2c The immediate cause of the crash is the access of txscrq in the following snippet during a reset, where the txscrq can be either NULL or an address that will soon be invalid: ibmvnicxmit() { ... txscrq = adapter->txscrq[queuenum]; txq = netdevgettxqueue(netdev, queuenum); indbufp = &txscrq->indbuf; if (testbit(0, &adapter->resetting)) { ... } But beyond that, the call to ibmvnicxmit() itself is not safe during a reset and the reset path attempts to avoid this by stopping the queue in ibmvniccleanup(). However just after the queue was stopped, an in-flight ibmvniccompletetx() could have restarted the queue even as the reset is progressing. Since the queue was restarted we could get a call to ibmvnicxmit() which can then access the bad txscrq (or other fields). We cannot however simply have ibmvniccompletetx() 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. ibmvniccompletetx() and others wake up the queue only if the queue is marked active. So we will have: A. reset/open thread in ibmvniccleanup() and ibmvnicopen() ->resetting = true ->txqueuesactive = false disable tx queues ... ->txqueuesactive = true start tx queues B. Tx interrupt in ibmvniccompletetx(): if (->txqueuesactive) netifwakesubqueue(); To ensure that ->txqueuesactive and state of the queues are consistent, we need a lock which: - must also be taken in the interrupt path (ibmvniccompletetx()) - shared across the multiple ---truncated---

Affected Software

120 affected componentsFixes available

ubuntu/linux-hwe-edge*

ubuntu/linux-aws-5.0*

ubuntu/linux-aws-5.3*

ubuntu/linux-aws-5.4<5.4.0-1165.176~18.04.1

5.4.0-1165.176~18.04.1

ubuntu/linux-azure*

ubuntu/linux-azure-5.3*

ubuntu/linux-azure-5.4<5.4.0-1170.176~18.04.1

5.4.0-1170.176~18.04.1

ubuntu/linux-azure-edge*

ubuntu/linux-gcp*

ubuntu/linux-gcp-5.3*

ubuntu/linux-gcp-5.4<5.4.0-1168.178~18.04.1

5.4.0-1168.178~18.04.1

ubuntu/linux-gke-4.15*

ubuntu/linux-gke-5.4*

ubuntu/linux-gkeop-5.4*

ubuntu/linux-hwe*

ubuntu/linux-hwe-5.4<5.4.0-242.262~18.04.1

5.4.0-242.262~18.04.1

ubuntu/linux-hwe-edge*

ubuntu/linux-ibm-5.4<5.4.0-1111.116~18.04.1

5.4.0-1111.116~18.04.1

ubuntu/linux-oem*

ubuntu/linux-oracle-5.0*

ubuntu/linux-oracle-5.3*

ubuntu/linux-oracle-5.4<5.4.0-1163.173~18.04.1

5.4.0-1163.173~18.04.1

ubuntu/linux-raspi-5.4<5.4.0-1148.161~18.04.1

5.4.0-1148.161~18.04.1

ubuntu/linux-azure-5.15<5.15.0-1008.9~20.04.1

5.15.0-1008.9~20.04.1

ubuntu/linux-hwe-5.15<5.15.0-41.44~20.04.1

5.15.0-41.44~20.04.1

ubuntu/linux-intel-iotg-5.15<5.15.0-1008.11~20.04.1

5.15.0-1008.11~20.04.1

ubuntu/linux-lowlatency-hwe-5.15<5.15.0-42.45~20.04.1

5.15.0-42.45~20.04.1

ubuntu/linux<5.4.0-242.262

5.4.0-242.262

ubuntu/linux-aws<5.4.0-1165.176

5.4.0-1165.176

ubuntu/linux-aws-5.11*

ubuntu/linux-aws-5.13*

ubuntu/linux-aws-5.8*

ubuntu/linux-azure<5.4.0-1170.176

5.4.0-1170.176

ubuntu/linux-azure-5.11*

ubuntu/linux-azure-5.13*

ubuntu/linux-azure-5.8*

ubuntu/linux-azure-fde*

ubuntu/linux-bluefield<5.4.0-1125.132

5.4.0-1125.132

ubuntu/linux-gcp<5.4.0-1168.178

5.4.0-1168.178

ubuntu/linux-gcp-5.11*

ubuntu/linux-gcp-5.13*

ubuntu/linux-gcp-5.8*

ubuntu/linux-gke*

ubuntu/linux-gke-5.15*

ubuntu/linux-gkeop*

ubuntu/linux-gkeop-5.15*

ubuntu/linux-hwe-5.11*

ubuntu/linux-hwe-5.13*

ubuntu/linux-hwe-5.8*

ubuntu/linux-ibm<5.4.0-1111.116

5.4.0-1111.116

ubuntu/linux-intel-5.13*

ubuntu/linux-iot<5.4.0-1069.72

5.4.0-1069.72

ubuntu/linux-kvm<5.4.0-1152.161

5.4.0-1152.161

ubuntu/linux-oem-5.10*

ubuntu/linux-oem-5.13*

ubuntu/linux-oem-5.6*

ubuntu/linux-oracle<5.4.0-1163.173

5.4.0-1163.173

ubuntu/linux-oracle-5.11*

ubuntu/linux-oracle-5.13*

ubuntu/linux-oracle-5.8*

ubuntu/linux-raspi<5.4.0-1148.161

5.4.0-1148.161

ubuntu/linux-raspi2*

ubuntu/linux-riscv*

ubuntu/linux-riscv-5.11*

ubuntu/linux-riscv-5.8*

ubuntu/linux-xilinx-zynqmp<5.4.0-1083.87

5.4.0-1083.87

ubuntu/linux-aws-fips<5.4.0-1165.176+fips1

5.4.0-1165.176+fips1

ubuntu/linux-azure-fips<5.4.0-1170.176+fips1

5.4.0-1170.176+fips1

ubuntu/linux-fips<5.4.0-1139.149

5.4.0-1139.149

ubuntu/linux-gcp-fips<5.4.0-1168.178+fips1

5.4.0-1168.178+fips1

ubuntu/linux-aws-fips*

ubuntu/linux-azure-fips*

ubuntu/linux-fips*

ubuntu/linux-gcp-fips*

ubuntu/linux<5.15.0-37.39

5.15.0-37.39

ubuntu/linux-allwinner-5.19*

ubuntu/linux-aws<5.15.0-1011.14

5.15.0-1011.14

ubuntu/linux-aws-5.19*

ubuntu/linux-aws-6.2*

ubuntu/linux-aws-6.5*

ubuntu/linux-azure<5.15.0-1010.12

5.15.0-1010.12

ubuntu/linux-azure-5.19*

ubuntu/linux-azure-6.2*

ubuntu/linux-azure-6.5*

ubuntu/linux-azure-fde-5.19*

ubuntu/linux-azure-fde-6.2*

ubuntu/linux-gcp<5.15.0-1008.12

5.15.0-1008.12

ubuntu/linux-gcp-5.19*

ubuntu/linux-gcp-6.2*

ubuntu/linux-gcp-6.5*

ubuntu/linux-gke<5.15.0-1008.10

5.15.0-1008.10

ubuntu/linux-hwe-5.19*

ubuntu/linux-hwe-6.2*

ubuntu/linux-hwe-6.5*

ubuntu/linux-ibm<5.15.0-1007.8

5.15.0-1007.8

ubuntu/linux-intel-iot-realtime*

ubuntu/linux-intel-iotg<5.15.0-1008.11

5.15.0-1008.11

ubuntu/linux-kvm<5.15.0-1010.11

5.15.0-1010.11

ubuntu/linux-lowlatency<5.15.0-37.39

5.15.0-37.39

ubuntu/linux-lowlatency-hwe-5.19*

ubuntu/linux-lowlatency-hwe-6.2*

ubuntu/linux-lowlatency-hwe-6.5*

ubuntu/linux-nvidia-6.2*

ubuntu/linux-nvidia-6.5*

ubuntu/linux-oem-5.17*

ubuntu/linux-oem-6.0*

ubuntu/linux-oem-6.1*

ubuntu/linux-oem-6.5*

ubuntu/linux-oracle<5.15.0-1009.12

5.15.0-1009.12

ubuntu/linux-oracle-6.5*

ubuntu/linux-raspi<5.15.0-1011.13

5.15.0-1011.13

ubuntu/linux-realtime*

ubuntu/linux-riscv*

ubuntu/linux-riscv-5.19*

ubuntu/linux-riscv-6.5*

ubuntu/linux-starfive-5.19*

ubuntu/linux-starfive-6.2*

ubuntu/linux-starfive-6.5*

ubuntu/linux-realtime<5.15.0-1014.14

5.15.0-1014.14

ubuntu/linux-raspi-realtime*

Remediation

Recommended actions to resolve this vulnerability, in priority order.

Upgrade
Upgrade ubuntu/linux-aws-5.4 to a version that resolves this vulnerability.
Fixed in 5.4.0-1165.176~18.04.1
Upgrade
Upgrade ubuntu/linux-azure-5.4 to a version that resolves this vulnerability.
Fixed in 5.4.0-1170.176~18.04.1
Upgrade
Upgrade ubuntu/linux-gcp-5.4 to a version that resolves this vulnerability.
Fixed in 5.4.0-1168.178~18.04.1
Upgrade
Upgrade ubuntu/linux-hwe-5.4 to a version that resolves this vulnerability.
Fixed in 5.4.0-242.262~18.04.1
Upgrade
Upgrade ubuntu/linux-ibm-5.4 to a version that resolves this vulnerability.
Fixed in 5.4.0-1111.116~18.04.1
Upgrade
Upgrade ubuntu/linux-oracle-5.4 to a version that resolves this vulnerability.
Fixed in 5.4.0-1163.173~18.04.1
Upgrade
Upgrade ubuntu/linux-raspi-5.4 to a version that resolves this vulnerability.
Fixed in 5.4.0-1148.161~18.04.1
Upgrade
Upgrade ubuntu/linux-azure-5.15 to a version that resolves this vulnerability.
Fixed in 5.15.0-1008.9~20.04.1
Upgrade
Upgrade ubuntu/linux-hwe-5.15 to a version that resolves this vulnerability.
Fixed in 5.15.0-41.44~20.04.1
Upgrade
Upgrade ubuntu/linux-intel-iotg-5.15 to a version that resolves this vulnerability.
Fixed in 5.15.0-1008.11~20.04.1
Upgrade
Upgrade ubuntu/linux-lowlatency-hwe-5.15 to a version that resolves this vulnerability.
Fixed in 5.15.0-42.45~20.04.1
Upgrade
Upgrade ubuntu/linux to a version that resolves this vulnerability.
Fixed in 5.4.0-242.262
Upgrade
Upgrade ubuntu/linux-aws to a version that resolves this vulnerability.
Fixed in 5.4.0-1165.176
Upgrade
Upgrade ubuntu/linux-azure to a version that resolves this vulnerability.
Fixed in 5.4.0-1170.176
Upgrade
Upgrade ubuntu/linux-bluefield to a version that resolves this vulnerability.
Fixed in 5.4.0-1125.132
Upgrade
Upgrade ubuntu/linux-gcp to a version that resolves this vulnerability.
Fixed in 5.4.0-1168.178
Upgrade
Upgrade ubuntu/linux-ibm to a version that resolves this vulnerability.
Fixed in 5.4.0-1111.116
Upgrade
Upgrade ubuntu/linux-iot to a version that resolves this vulnerability.
Fixed in 5.4.0-1069.72
Upgrade
Upgrade ubuntu/linux-kvm to a version that resolves this vulnerability.
Fixed in 5.4.0-1152.161
Upgrade
Upgrade ubuntu/linux-oracle to a version that resolves this vulnerability.
Fixed in 5.4.0-1163.173
Upgrade
Upgrade ubuntu/linux-raspi to a version that resolves this vulnerability.
Fixed in 5.4.0-1148.161
Upgrade
Upgrade ubuntu/linux-xilinx-zynqmp to a version that resolves this vulnerability.
Fixed in 5.4.0-1083.87
Upgrade
Upgrade ubuntu/linux-aws-fips to a version that resolves this vulnerability.
Fixed in 5.4.0-1165.176+fips1
Upgrade
Upgrade ubuntu/linux-azure-fips to a version that resolves this vulnerability.
Fixed in 5.4.0-1170.176+fips1
Upgrade
Upgrade ubuntu/linux-fips to a version that resolves this vulnerability.
Fixed in 5.4.0-1139.149
Upgrade
Upgrade ubuntu/linux-gcp-fips to a version that resolves this vulnerability.
Fixed in 5.4.0-1168.178+fips1
Upgrade
Upgrade ubuntu/linux to a version that resolves this vulnerability.
Fixed in 5.15.0-37.39
Upgrade
Upgrade ubuntu/linux-aws to a version that resolves this vulnerability.
Fixed in 5.15.0-1011.14
Upgrade
Upgrade ubuntu/linux-azure to a version that resolves this vulnerability.
Fixed in 5.15.0-1010.12
Upgrade
Upgrade ubuntu/linux-gcp to a version that resolves this vulnerability.
Fixed in 5.15.0-1008.12
Upgrade
Upgrade ubuntu/linux-gke to a version that resolves this vulnerability.
Fixed in 5.15.0-1008.10
Upgrade
Upgrade ubuntu/linux-ibm to a version that resolves this vulnerability.
Fixed in 5.15.0-1007.8
Upgrade
Upgrade ubuntu/linux-intel-iotg to a version that resolves this vulnerability.
Fixed in 5.15.0-1008.11
Upgrade
Upgrade ubuntu/linux-kvm to a version that resolves this vulnerability.
Fixed in 5.15.0-1010.11
Upgrade
Upgrade ubuntu/linux-lowlatency to a version that resolves this vulnerability.
Fixed in 5.15.0-37.39
Upgrade
Upgrade ubuntu/linux-oracle to a version that resolves this vulnerability.
Fixed in 5.15.0-1009.12
Upgrade
Upgrade ubuntu/linux-raspi to a version that resolves this vulnerability.
Fixed in 5.15.0-1011.13
Upgrade
Upgrade ubuntu/linux-realtime to a version that resolves this vulnerability.
Fixed in 5.15.0-1014.14

Event History

Feb 26, 2025

CVE Published

via OSV·07:00 AM

Data Sourced

via OSV·07:00 AM

DescriptionSeverityAffected Software

Frequently Asked Questions

Which systems are most likely to be exposed?

Systems using the ibmvnic network driver are implicated. The affected Ubuntu kernel package families listed are linux, linux-aws, linux-azure, linux-gcp, linux-gke, linux-hwe-edge, linux-ibm, and linux-kvm.

What access and conditions are required for exploitation?

The supplied CVSS vector indicates local access, low privileges, no user interaction, and high attack complexity. The failure requires a race between the transmit path and a reset path, causing ibmvnic_xmit() to access an SCRQ after reset has freed it.

How might an affected system behave?

The documented impact is a kernel crash caused by a NULL pointer dereference during transmission. Crash output may identify ibmvnic_xmit in the call trace and include messages such as "Kernel NULL pointer dereference" or "Kernel access of bad area."}]}

UBUNTU-CVE-2022-49201: Null Pointer Dereference

Affected Software

Remediation

Event History

Frequently Asked Questions

Which systems are most likely to be exposed?

What access and conditions are required for exploitation?

How might an affected system behave?

Company

Resources

Contact

Frequently Asked Questions

Which systems are most likely to be exposed?

What access and conditions are required for exploitation?

How might an affected system behave?