EUVD-2026-108758
GHSA-8vjr-8rg3-pvjv
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessConnect to NVMe-oF target over fabric
-
DeliveryIssue I/O requiring P2P metadata SGL
-
ExploitMetadata allocation fails after data succeeds
-
ExecutionCleanup frees via unassigned p2p_dev
-
ImpactKernel crash / target denial of service
Vulnerability Assessment
| Exploitation Conditions | Exploitation requires the system to be acting as a Linux NVMe-oF target (nvmet) configured to use PCI peer-to-peer (P2P) DMA memory with namespace metadata/protection-information enabled - a non-default, specialized deployment. The specific trigger is that nvmet_req_alloc_p2pmem_sgls() must have its data SGL allocation succeed but its metadata SGL allocation fail, so the out_free_sg cleanup runs before req->p2p_dev is assigned. That allocation failure is a resource-exhaustion condition on the P2P memory pool and is not directly attacker-controlled, which materially limits exploitability despite the AV:N/AC:L raw vector. Systems not configured for nvmet P2P with metadata are not affected. |
| Impact | Raw CVSS is 7.5 HIGH with vector AV:N/AC:L/PR:N/UI:N and availability-only impact (C:N/I:N/A:H), which on paper reads as a trivially remote, unauthenticated kernel crash. The supporting signals argue for a much lower real-world priority: EPSS is 0.21% (10th percentile), there is no CISA KEV listing, and the only references are the git.kernel.org stable fix commits plus the NVD entry - no public exploit identified. The vuln.today decision label is 'this_week', a routine patch cadence rather than act_now/emergency. The CVSS AC:L is also in tension with the mechanism: the description shows the bug is only reached when a nvmet target is configured with PCI P2P memory and metadata, AND the metadata SGL allocation fails after the data allocation succeeds - an out-of-memory error-cleanup path, not a condition an attacker controls directly. The 'Information Disclosure' tag further conflicts with the C:N impact; this is an availability (crash) issue, not disclosure. Net: a legitimate kernel DoS bug on a narrow NVMe-oF target error path, worth patching on normal stable-update schedule, not an emergency. |
| Exploit ScenarioDerived | A host connected to a Linux NVMe-oF target that is configured with PCI peer-to-peer (P2P) DMA memory and namespace metadata/protection-information issues I/O that drives the P2P pool to exhaustion, so the metadata SGL allocation fails after the data allocation has already succeeded. The error-cleanup path (out_free_sg) then passes the not-yet-assigned req->p2p_dev to pci_p2pmem_free_sgl(), dereferencing an invalid device pointer and crashing the target kernel (denial of service). No public exploit code was identified at time of analysis. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 24, 2026
Kernel crashes in the Linux NVMe-oF target (nvmet) when a PCI peer-to-peer metadata allocation fails, because the cleanup path releases the successfully allocated data SGL against a req->p2p_dev device reference that has not yet been assigned, instead of the local p2p_dev used for the successful allocation. Only systems acting as an NVMe-oF target with P2P DMA memory and namespace metadata/protection information enabled are exposed, a non-default and specialised configuration; the failure itself is a P2P memory pool exhaustion condition rather than something an attacker directly controls, which is why our assessment raises the complexity to AC:H despite the vendor's AV:N/AC:L scoring. Impact is availability-only (C:N/I:N/A:H), EPSS is a low 0.21% (10th percentile), the issue is not listed in CISA KEV, and no public exploit has been identified at time of analysis.
RemediationAI
Apply the upstream stable fix, which passes the local p2p_dev to the cleanup instead of req->p2p_dev; the tagged fixed releases reported by EUVD are Linux 6.6.160, 6.12.113, 6.18.57 and 7.2.11, and the corresponding stable commits are https://git.kernel.org/stable/c/3c231142c4f4bb96836469eb276026ec55940093, https://git.kernel.org/stable/c/32f21607911a1f69c8f0f93a6c28fe6f8490aa98, https://git.kernel.org/stable/c/ce79a6c5cc1b8054ec8d3eba16adda4a36113438, https://git.kernel.org/stable/c/73bf0f9579633b531098a475e6e55c9316763aed and https://git.kernel.org/stable/c/4aa9c0f377a4de5e8fddce76b34ee4529639a1ff. If patching cannot be scheduled immediately, the vulnerable path can be taken out of scope by not enabling PCI P2P DMA memory for the nvmet target, or by disabling namespace metadata/protection information (PI) on P2P-backed namespaces - the trade-off being loss of end-to-end data-integrity checking on those namespaces and loss of P2P DMA performance benefit, since the target falls back to regular host memory. Note that the trigger is a P2P memory pool exhaustion during metadata allocation rather than an attacker-supplied input, so exposure is largely governed by how constrained that pool is under normal load; there is no separate vendor workaround beyond updating.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
nvmet (the NVMe over Fabrics target subsystem) can back request data and metadata scatter-gather lists with PCI peer-to-peer DMA memory obtained through the pci_p2pmem interfaces. nvmet_req_alloc_p2pmem_sgls() allocates the data SGL first and the metadata SGL second, and assigns req->p2p_dev only after both allocations succeed; nvmet_req_free_p2pmem_sgls()/the out_free_sg error path then calls pci_p2pmem_free_sgl() with req->p2p_dev. When the data allocation succeeds but the metadata allocation fails - a resource-exhaustion condition on the P2P memory pool - that cleanup runs while req->p2p_dev still holds no assigned device, so the free is performed against a device reference that does not correspond to the one used for the successful data allocation. The upstream fix passes the local p2p_dev argument into the cleanup so both allocation and free are scoped to the same PCI device. No CWE was supplied with the record; the defect class is an error-path cleanup bug (use of an unassigned device reference) rather than a memory-safety flaw in the data path. Note that the accompanying 'Information Disclosure' tag is inconsistent with both the vendor vector and our assessment, which are availability-only.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Reachable over the NVMe-oF fabric (AV:N), but needs non-default P2P+metadata config and a metadata-allocation failure not under attacker control (AC:H); crash only, so A:H with C:N/I:N.
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
Lifecycle Timeline
4DescriptionCVE.org
In the Linux kernel, the following vulnerability has been resolved:
nvmet: use the local P2P device on metadata allocation failure
nvmet_req_alloc_p2pmem_sgls() assigns req->p2p_dev only after the data and metadata SGL allocations succeed. If the data allocation succeeds but the metadata allocation fails, out_free_sg passes req->p2p_dev to pci_p2pmem_free_sgl() before that assignment has taken place.
Pass the local p2p_dev argument instead, so cleanup uses the same PCI device as the successful data allocation.
Executive ViewAI
A flaw in the Linux kernel's NVMe over Fabrics target could crash only specialized storage systems configured for peer-to-peer DMA and namespace metadata, potentially disrupting storage services. Leadership should care because a small number of high-value storage nodes might be affected, but exploitation is unlikely and the impact is limited to availability.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
Exploit-DB