In the Linux kernel, the following vulnerability has been resolved:
nvmet: always initialize cqe.result
The spec doesn't mandate that the first two double words (aka results)
for the command queue entry need to be set to 0 when they are not
used (not specified). Though, the target implemention returns 0 for TCP
and FC but not for RDMA.
Let's make RDMA behave the same and thus explicitly initializing the
result field. This prevents leaking any data from the stack.
Security readout for executives and security teams
Plain-English summary
A Linux NVMe target using RDMA may return uninitialized kernel stack data in a command completion. A remote, unauthenticated client could potentially receive sensitive memory contents. The issue affects confidentiality; the supplied CVSS assessment does not indicate data modification or service disruption.
Executive priority
Prioritize internet-accessible or broadly reachable NVMe-over-RDMA targets and systems handling sensitive workloads. Patch through normal emergency vulnerability procedures after compatibility testing. Lower the priority for systems that do not provide the affected RDMA target service, while documenting evidence supporting that conclusion.
Technical view
The NVMe target RDMA path did not always initialize cqe.result when a command had no defined result. Consequently, completion entries could contain residual stack data. TCP and Fibre Channel paths already returned zero; the kernel correction explicitly initializes the field so RDMA behaves consistently.
Likely exposure
Exposure is concentrated on Linux systems configured as NVMe targets over RDMA and running an affected kernel build. Ordinary Linux hosts, NVMe initiators, and target deployments using only TCP or Fibre Channel are not shown as vulnerable by the supplied evidence. Exact distribution-specific version boundaries require vendor confirmation.
Exploitation context
The CVSS 3.1 score is 7.5, reflecting network-accessible, low-complexity, unauthenticated confidentiality impact. The bundle marks this CVE as absent from KEV, and no supplied source reports active exploitation. Practical leakage volume, repeatability, and the sensitivity of exposed stack contents are not established.
Researcher notes
This is an information-disclosure flaw caused by an uninitialized completion-result field, not a demonstrated memory-write primitive. Analysis should focus on nvmet's RDMA transport and whether completion responses can expose residual stack bytes. The supplied affected-version list is internally ambiguous, so commit ancestry and distribution backports should be checked before declaring exposure.
Mitigation direction
Apply a vendor-supported kernel update containing the cited nvmet RDMA initialization correction.
Consult the Linux distribution or appliance vendor for exact affected and fixed build mappings.
Restrict NVMe-over-RDMA access to trusted storage networks while patching is pending.
Disable unused NVMe target RDMA functionality where operationally safe.
Validation and detection
Identify systems providing NVMe target services over RDMA, not merely using NVMe storage.
Record each exposed system's exact kernel and distribution package versions.
Compare installed builds with vendor advisories and the cited stable-kernel corrections.
After updating, confirm the fixed kernel is running and NVMe target operations remain functional.
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-2024-41079 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.
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.