In the Linux kernel, the following vulnerability has been resolved:
PCI: Fix NULL dereference in SR-IOV VF creation error path
Clean up when virtfn setup fails to prevent NULL pointer dereference
during device removal. The kernel oops below occurred due to incorrect
error handling flow when pci_setup_device() fails.
Add pci_iov_scan_device(), which handles virtfn allocation and setup and
cleans up if pci_setup_device() fails, so pci_iov_add_virtfn() doesn't need
to call pci_stop_and_remove_bus_device(). This prevents accessing
partially initialized virtfn devices during removal.
BUG: kernel NULL pointer dereference, address: 00000000000000d0
RIP: 0010:device_del+0x3d/0x3d0
Call Trace:
pci_remove_bus_device+0x7c/0x100
pci_iov_add_virtfn+0xfa/0x200
sriov_enable+0x208/0x420
mlx5_core_sriov_configure+0x6a/0x160 [mlx5_core]
sriov_numvfs_store+0xae/0x1a0
[bhelgaas: commit log, return ERR_PTR(-ENOMEM) directly]
Security readout for executives and security teams
Plain-English summary
This Linux kernel flaw can crash affected systems when SR-IOV virtual PCI function setup fails and cleanup touches a partially initialized device. The likely business impact is availability loss on hosts using SR-IOV, especially virtualization or high-performance networking systems.
Executive priority
Treat as a targeted availability risk for infrastructure using SR-IOV. Prioritize patching on virtualization and high-performance networking hosts, but avoid emergency escalation unless vendor guidance or local evidence shows active impact.
Technical view
The PCI SR-IOV VF creation error path could leave a partially initialized virtfn object. If pci_setup_device() failed, later removal could dereference NULL in device_del(), producing a kernel oops. Stable fixes add pci_iov_scan_device() to centralize allocation, setup, and cleanup.
Likely exposure
Exposure is most likely on Linux hosts that enable PCI SR-IOV virtual functions, such as virtualization, NIC, or accelerator environments. General Linux systems not using SR-IOV are less likely to encounter the vulnerable path.
Exploitation context
The bundle does not show KEV listing, public exploitation, CVSS, or a complete attacker model. The available evidence shows a kernel oops during SR-IOV VF creation failure handling, not remote code execution.
Researcher notes
Evidence is limited to the CVE record and kernel stable references. The record names the failing path and fix approach, but does not provide CVSS, CWE, exploitability details, or distribution-specific affected package ranges.
Mitigation direction
Apply vendor kernel updates containing the referenced stable fixes.
Prioritize hosts using PCI SR-IOV virtual functions.
Check Linux distribution advisories for backported fixes.
Avoid unnecessary SR-IOV enablement on exposed or unstable hosts.
Monitor kernel logs for NULL dereference oops in SR-IOV paths.
Validation and detection
Inventory Linux kernel versions on SR-IOV-capable hosts.
Confirm whether SR-IOV virtual functions are enabled.
Map installed kernels to distribution advisories or stable commits.
Review logs for device_del or pci_iov_add_virtfn oops traces.
Verify patched kernels after maintenance reboot or live patching.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2025-22092 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
4Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Apr 16, 2025, 14:12 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.