CVE-2022-49003 in Linux
Summary
by MITRE • 10/21/2024
In the Linux kernel, the following vulnerability has been resolved:
nvme: fix SRCU protection of nvme_ns_head list
Walking the nvme_ns_head siblings list is protected by the head's srcu in nvme_ns_head_submit_bio() but not nvme_mpath_revalidate_paths(). Removing namespaces from the list also fails to synchronize the srcu. Concurrent scan work can therefore cause use-after-frees.
Hold the head's srcu lock in nvme_mpath_revalidate_paths() and synchronize with the srcu, not the global RCU, in nvme_ns_remove().
Observed the following panic when making NVMe/RDMA connections with native multipath on the Rocky Linux 8.6 kernel (it seems the upstream kernel has the same race condition). Disassembly shows the faulting instruction is cmp 0x50(%rdx),%rcx; computing capacity != get_capacity(ns->disk). Address 0x50 is dereferenced because ns->disk is NULL. The NULL disk appears to be the result of concurrent scan work freeing the namespace (note the log line in the middle of the panic).
[37314.206036] BUG: unable to handle kernel NULL pointer dereference at 0000000000000050
[37314.206036] nvme0n3: detected capacity change from 0 to 11811160064
[37314.299753] PGD 0 P4D 0
[37314.299756] Oops: 0000 [#1] SMP PTI
[37314.299759] CPU: 29 PID: 322046 Comm: kworker/u98:3 Kdump: loaded Tainted: G W X --------- - - 4.18.0-372.32.1.el8test86.x86_64 #1
[37314.299762] Hardware name: Dell Inc. PowerEdge R720/0JP31P, BIOS 2.7.0 05/23/2018
[37314.299763] Workqueue: nvme-wq nvme_scan_work [nvme_core]
[37314.299783] RIP: 0010:nvme_mpath_revalidate_paths+0x26/0xb0 [nvme_core]
[37314.299790] Code: 1f 44 00 00 66 66 66 66 90 55 53 48 8b 5f 50 48 8b 83 c8 c9 00 00 48 8b 13 48 8b 48 50 48 39 d3 74 20 48 8d 42 d0 48 8b 50 20 3b 4a 50 74 05 f0 80 60 70 ef 48 8b 50 30 48 8d 42 d0 48 39 d3
[37315.058803] RSP: 0018:ffffabe28f913d10 EFLAGS: 00010202
[37315.121316] RAX: ffff927a077da800 RBX: ffff92991dd70000 RCX: 0000000001600000
[37315.206704] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff92991b719800
[37315.292106] RBP: ffff929a6b70c000 R08: 000000010234cd4a R09: c0000000ffff7fff
[37315.377501] R10: 0000000000000001 R11: ffffabe28f913a30 R12: 0000000000000000
[37315.462889] R13: ffff92992716600c R14: ffff929964e6e030 R15: ffff92991dd70000
[37315.548286] FS: 0000000000000000(0000) GS:ffff92b87fb80000(0000) knlGS:0000000000000000
[37315.645111] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[37315.713871] CR2: 0000000000000050 CR3: 0000002208810006 CR4: 00000000000606e0
[37315.799267] Call Trace:
[37315.828515] nvme_update_ns_info+0x1ac/0x250 [nvme_core]
[37315.892075] nvme_validate_or_alloc_ns+0x2ff/0xa00 [nvme_core]
[37315.961871] ? __blk_mq_free_request+0x6b/0x90
[37316.015021] nvme_scan_work+0x151/0x240 [nvme_core]
[37316.073371] process_one_work+0x1a7/0x360
[37316.121318] ? create_worker+0x1a0/0x1a0
[37316.168227] worker_thread+0x30/0x390
[37316.212024] ? create_worker+0x1a0/0x1a0
[37316.258939] kthread+0x10a/0x120
[37316.297557] ? set_kthread_struct+0x50/0x50
[37316.347590] ret_from_fork+0x35/0x40
[37316.390360] Modules linked in: nvme_rdma nvme_tcp(X) nvme_fabrics nvme_core netconsole iscsi_tcp libiscsi_tcp dm_queue_length dm_service_time nf_conntrack_netlink br_netfilter bridge stp llc overlay nft_chain_nat ipt_MASQUERADE nf_nat xt_addrtype xt_CT nft_counter xt_state xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment xt_multiport nft_compat nf_tables libcrc32c nfnetlink dm_multipath tg3 rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm intel_rapl_msr iTCO_wdt iTCO_vendor_support dcdbas intel_rapl_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel ipmi_ssif kvm irqbypass crct10dif_pclmul crc32_pclmul mlx5_ib ghash_clmulni_intel ib_uverbs rapl intel_cstate intel_uncore ib_core ipmi_si joydev mei_me pcspkr ipmi_devintf mei lpc_ich wmi ipmi_msghandler acpi_power_meter ex
---truncated---
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 01/18/2026
The vulnerability identified as CVE-2022-49003 resides within the Linux kernel's NVMe subsystem, specifically affecting the handling of namespace lists in multipath configurations. This flaw manifests as a race condition that can lead to use-after-free errors when concurrent operations attempt to access and modify the nvme_ns_head list. The root cause lies in inconsistent synchronization mechanisms used during namespace revalidation and removal processes, creating a scenario where one thread may attempt to access a freed memory location while another thread is in the process of deallocating it. The issue is particularly critical in environments utilizing NVMe/RDMA connections with native multipath support, as demonstrated by the observed kernel panic on Rocky Linux 8.6 systems.
The technical flaw stems from improper protection of the nvme_ns_head list traversal mechanism. While the function nvme_ns_head_submit_bio() correctly employs the head's SRCU (Sleepable Read-Copy Update) mechanism to protect access to the siblings list, the function nvme_mpath_revalidate_paths() fails to acquire the same protection. This discrepancy allows for a window where concurrent scan work can remove namespaces from the list without proper synchronization, leading to potential memory corruption. The synchronization failure occurs during namespace removal in nvme_ns_remove(), which does not properly synchronize with the SRCU, instead relying on global RCU mechanisms that are insufficient for this specific context. This inconsistency creates a path for memory safety violations when multiple threads operate simultaneously on the same namespace list structure.
The operational impact of this vulnerability is severe, particularly in high-concurrency storage environments where NVMe multipath configurations are prevalent. The observed kernel panic demonstrates the system's inability to handle concurrent namespace operations gracefully, resulting in NULL pointer dereferences that cause immediate system instability. The faulting instruction at address 0x50, attempting to access ns->disk which becomes NULL due to concurrent scan work freeing the namespace, indicates a classic use-after-free condition. This condition can lead to system crashes, data corruption, and potential denial of service in production environments. The vulnerability affects not only Rocky Linux 8.6 but also upstream kernels, indicating a widespread exposure across multiple kernel versions and distributions that implement NVMe multipath functionality.
Mitigation strategies for this vulnerability require careful attention to the synchronization mechanisms within the NVMe subsystem. The fix involves ensuring that nvme_mpath_revalidate_paths() properly holds the head's SRCU lock during list traversal operations, preventing concurrent modifications while maintaining access to the namespace list. Additionally, the nvme_ns_remove() function must be updated to synchronize with the SRCU rather than relying on global RCU mechanisms, ensuring that all modifications to the namespace list are properly coordinated. These changes align with established security practices for concurrent data structure access and memory management in kernel space. Organizations should prioritize applying kernel updates that contain the patched implementation, while system administrators should monitor for potential system instability in environments utilizing NVMe multipath configurations. The vulnerability's classification under CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization) and its mapping to ATT&CK technique T1484.001 (Domain Policy Modification) highlights the critical nature of proper kernel synchronization and the potential for privilege escalation through system instability.