CVE-2025-38658: nvmet: pci-epf: Do not complete commands twice if nvmet_req_init() fails
In the Linux kernel, the following vulnerability has been resolved:
nvmet: pci-epf: Do not complete commands twice if nvmet_req_init() fails
Have nvmet_req_init() and req->execute() complete failed commands.
Description of the problem:
nvmet_req_init() calls __nvmet_req_complete() internally upon failure,
e.g., unsupported opcode, which calls the "queue_response" callback,
this results in nvmet_pci_epf_queue_response() being called, which will
call nvmet_pci_epf_complete_iod() if data_len is 0 or if dma_dir is
different from DMA_TO_DEVICE. This results in a double completion as
nvmet_pci_epf_exec_iod_work() also calls nvmet_pci_epf_complete_iod()
when nvmet_req_init() fails.
Steps to reproduce:
On the host send a command with an unsupported opcode with nvme-cli,
For example the admin command "security receive"
$ sudo nvme security-recv /dev/nvme0n1 -n1 -x4096
This triggers a double completion as nvmet_req_init() fails and
nvmet_pci_epf_queue_response() is called, here iod->dma_dir is still
in the default state of "DMA_NONE" as set by default in
nvmet_pci_epf_alloc_iod(), so nvmet_pci_epf_complete_iod() is called.
Because nvmet_req_init() failed nvmet_pci_epf_complete_iod() is also
called in nvmet_pci_epf_exec_iod_work() leading to a double completion.
This not only sends two completions to the host but also corrupts the
state of the PCI NVMe target leading to kernel oops.
This patch lets nvmet_req_init() and req->execute() complete all failed
commands, and removes the double completion case in
nvmet_pci_epf_exec_iod_work() therefore fixing the edge cases where
double completions occurred.
Security readout for executives and security teams
Plain-English summary
A flaw in the Linux NVMe PCI endpoint target can process a failed command completion twice. This can corrupt target state and crash the kernel. Business risk is concentrated in systems operating this specialized NVMe target function, where disruption or broader compromise may be possible according to the CVSS assessment.
Executive priority
Treat as a high-priority update for systems providing PCI endpoint NVMe targets, especially where adjacent systems are untrusted. Broader fleet urgency depends on whether this specialized functionality is deployed. Require rapid inventory and vendor-confirmed patching rather than assuming every Linux system is exposed.
Technical view
When nvmet_req_init() rejects a command, it already completes the request through queue_response. nvmet_pci_epf_exec_iod_work() could then complete the same I/O again, producing duplicate host responses, corrupting PCI NVMe target state, and causing a kernel oops. The stable patches remove this second completion path.
Likely exposure
Exposure appears limited to Linux systems using the NVMe target PCI endpoint-function implementation. Ordinary Linux hosts not providing this target function are unlikely to reach the vulnerable path. The supplied version metadata is ambiguous, so confirm exposure against distribution advisories and the referenced stable commits.
Exploitation context
The CVSS score is 8.8 and describes adjacent access, low complexity, no privileges, and no user interaction. The source demonstrates that an unsupported NVMe command can trigger the defect. CISA KEV status is false, and the supplied sources provide no evidence of active exploitation.
Researcher notes
The defect is a double-completion lifecycle error in nvmet PCI EPF failure handling. The documented trigger is command rejection during nvmet_req_init(), before dma_dir leaves DMA_NONE. Two stable commits are referenced, but the supplied version representation does not clearly express fixed ranges. No CWE or active-exploitation evidence is provided.
Mitigation direction
Install a vendor kernel update containing the referenced stable fix or an equivalent backport.
Confirm the selected distribution package explicitly addresses CVE-2025-38658.
Prioritize NVMe PCI endpoint target systems over hosts that do not use this functionality.
If updates are unavailable, obtain temporary mitigation guidance from the kernel or distribution vendor.
Validation and detection
Inventory systems running Linux NVMe target PCI endpoint-function functionality.
Record kernel and distribution package versions on potentially exposed target systems.
Check package changelogs or source trees for either referenced stable fix commit.
Review kernel logs for oops events associated with the PCI NVMe target.
Avoid reproducing the fault on production systems because it can corrupt state and crash the kernel.
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-38658 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.
1CVSS vectors
3Timeline events
0ADP providers
3Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.