CVE-2024-41079

What it actually does

In the Linux kernel nvmet RDMA target, the NVMe completion queue entry result field is not explicitly initialized before being returned to the initiator, allowing uninitialized stack memory to be sent over the RDMA connection instead of zeroed values.

Why it matters to the business

Organizations using Linux-based NVMe-oF targets over RDMA may inadvertently expose residual kernel stack contents containing sensitive data such as credentials or internal structures to remote initiators, increasing the risk of information leakage in storage fabrics.

How an attack unfolds

An attacker with the ability to connect as an NVMe-oF initiator over RDMA issues commands that trigger the nvmet response path; because the result field is not zeroed on RDMA (unlike TCP/FC), the response carries whatever data previously occupied that stack location, which the attacker then inspects in the received CQE.

How to fix it

Update the Linux kernel to a version containing commit 30d35b24b7957922f81cfdaa66f2e1b1e9b9aed2 or later; rebuild and deploy the updated kernel on all systems acting as nvmet RDMA targets.

How to confirm the fix worked

Confirm the running kernel contains commit 30d35b24b7957922f81cfdaa66f2e1b1e9b9aed2; inspect the nvmet_rdma source to verify cqe.result is explicitly zeroed before posting completions; test by sending commands and verifying result fields contain only zeros.

Typical attack path

1. Establish RDMA connection to a vulnerable nvmet target
2. Issue NVMe commands whose completion paths do not populate the result double-words
3. Observe the raw CQE payload returned over RDMA for residual stack data
4. Extract and analyze any leaked kernel memory contents

How to detect it

Review kernel source history or running kernel version for presence of the initializing commit; examine RDMA completion traces or packet captures for non-zero values in the first two double-words of CQEs when the spec does not require them; no post-exploitation artifacts are typically left on disk.

What your security team should do

• Prioritize patching all nvmet RDMA target systems within the next maintenance window due to the kernel-wide exposure
• Audit environments for use of RDMA transport with nvmet and restrict initiator access to trusted endpoints only
• Monitor upstream stable kernel releases for backports of the fix into distribution kernels