Goal Reached Thanks to every supporter — we hit 100%!

Goal: 1000 CNY · Raised: 1310 CNY

100%

CVE-2022-49201— ibmvnic: fix race between xmit and reset

AI Predicted 5.5 Difficulty: Hard EPSS 0.02% · P4

Affected Version Matrix 10

VendorProductVersion RangeStatus
LinuxLinux7ed5b31f4a6695a21f617df07646e9b15c6c1d29< 1bd58abf595b6cf1ba6dd47ec887c4c009155fc9affected
7ed5b31f4a6695a21f617df07646e9b15c6c1d29< 475f9cce98b63bc145b4efa66fa51175d4cb345faffected
7ed5b31f4a6695a21f617df07646e9b15c6c1d29< 8507c6ade73cdbbbda5c3d31d67f52f2e1cf03feaffected
7ed5b31f4a6695a21f617df07646e9b15c6c1d29< 4219196d1f662cb10a462eb9e076633a3fc31a15affected
5.4affected
< 5.4unaffected
5.15.33≤ 5.15.*unaffected
5.16.19≤ 5.16.*unaffected
… +2 more rows
Get alerts for future matching vulnerabilitiesLog in to subscribe

I. Basic Information for CVE-2022-49201

Vulnerability Information

Have questions about the vulnerability? See if Shenlong's analysis helps!
View Shenlong Deep Dive ↗

Although we use advanced large model technology, its output may still contain inaccurate or outdated information.Shenlong tries to ensure data accuracy, but please verify and judge based on the actual situation.

Vulnerability Title
ibmvnic: fix race between xmit and reset
Source: NVD (National Vulnerability Database)
Vulnerability 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: 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---
Source: NVD (National Vulnerability Database)
CVSS Information
N/A
Source: NVD (National Vulnerability Database)
Vulnerability Type
N/A
Source: NVD (National Vulnerability Database)
Vulnerability Title
Linux kernel 安全漏洞
Source: CNNVD (China National Vulnerability Database)
Vulnerability Description
Linux kernel是美国Linux基金会的开源操作系统Linux所使用的内核。 Linux kernel存在安全漏洞,该漏洞源于ibmvnic_xmit和重置路径之间存在竞争条件,可能导致空指针取消引用。
Source: CNNVD (China National Vulnerability Database)
CVSS Information
N/A
Source: CNNVD (China National Vulnerability Database)
Vulnerability Type
N/A
Source: CNNVD (China National Vulnerability Database)

Affected Products

VendorProductAffected VersionsCPESubscribe
LinuxLinux 7ed5b31f4a6695a21f617df07646e9b15c6c1d29 ~ 1bd58abf595b6cf1ba6dd47ec887c4c009155fc9 -
LinuxLinux 5.4 -

II. Public POCs for CVE-2022-49201

#POC DescriptionSource LinkShenlong Link
AI-Generated POCPremium

No public POC found.

Login to generate AI POC

III. Intelligence Information for CVE-2022-49201

登录查看更多情报信息。

Patches & Fixes for CVE-2022-49201 (4)

Same Patch Batch · Linux · 2025-02-26 · 706 CVEs total

CVE-2022-49498ALSA: pcm: Check for null pointer of pointer substream before dereferencing it
CVE-2022-49486ASoC: fsl: Fix refcount leak in imx_sgtl5000_probe
CVE-2022-49488drm/msm/mdp5: Return error code in mdp5_mixer_release when deadlock is detected
CVE-2022-49489drm/msm/disp/dpu1: set vbif hw config to NULL to avoid use after memory free during pm run
CVE-2022-49490drm/msm/mdp5: Return error code in mdp5_pipe_release when deadlock is detected
CVE-2022-49491drm/rockchip: vop: fix possible null-ptr-deref in vop_bind()
CVE-2022-49492nvme-pci: fix a NULL pointer dereference in nvme_alloc_admin_tags
CVE-2022-49493ASoC: rt5645: Fix errorenous cleanup order
CVE-2022-49494mtd: rawnand: cadence: fix possible null-ptr-deref in cadence_nand_dt_probe()
CVE-2022-49495drm/msm/hdmi: check return value after calling platform_get_resource_byname()
CVE-2022-49497net: remove two BUG() from skb_checksum_help()
CVE-2022-49496media: mediatek: vcodec: prevent kernel crash when rmmod mtk-vcodec-dec.ko
CVE-2022-49502media: rga: fix possible memory leak in rga_probe
CVE-2022-49507regulator: da9121: Fix uninit-value in da9121_assign_chip_model()
CVE-2022-49508HID: elan: Fix potential double free in elan_input_configured
CVE-2022-49506drm/mediatek: Add vblank register/unregister callback functions
CVE-2022-49504scsi: lpfc: Inhibit aborts if external loopback plug is inserted
CVE-2022-49505NFC: NULL out the dev->rfkill to prevent UAF
CVE-2022-49501usbnet: Run unregister_netdev() before unbind() again
CVE-2022-49500wl1251: dynamically allocate memory used for DMA

Showing top 20 of 706 CVEs. View all on vendor page &rarr; →

IV. Related Vulnerabilities

V. Comments for CVE-2022-49201

No comments yet


Leave a comment