CVE-2026-89481: nvme-tcp: fix host memory disclosure on R2T for a read command

Published Sep 11, 2026
·
Updated

In the Linux kernel, the following vulnerability has been resolved:

nvme-tcp: fix host memory disclosure on R2T for a read command

nvmetcphandler2t() does not check the direction of the request the R2T refers to. A malicious controller can send an R2T for a READ and the host will answer it: nvmetcpsetuph2cdatapdu() builds the H2CData header and nvmetcptrysenddata() sends the request's data buffer. That buffer is the READ destination, so its contents go to the controller.

The command then completes normally and nothing is logged.

Against a test controller that answers every READ with an R2T, a 4096 byte buffered read returned all 4096 bytes, split over two R2Ts. The pages contained stale kernel data, including an array of struct page pointers.

Reject an R2T for a request that is not a write.

Affected Software

1 affected component
Linux Linux kernel

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Configuration

    Update the Linux kernel nvme-tcp code path so that nvme_tcp_handle_r2t() rejects an R2T when the associated request is not a write (i.e., do not use READ destination buffers for R2T handling that could disclose stale host memory).

    Linux kernel nvme-tcp R2T handling for READ direction = Reject an R2T for a request that is not a write

Event History

Sep 11, 2026
CVE Published
via MITRE·07:43 PM
Data Sourced
via MITRE·07:43 PM
Description

Frequently Asked Questions

1

Which systems are exposed to disclosure?

Linux hosts using NVMe/TCP are exposed when they issue read commands to a malicious controller. The controller can cause the host to transmit the read destination buffer back to the controller.

2

What does an attacker need to exploit this issue?

The attacker needs to operate or control an NVMe/TCP controller that can send an R2T message in response to a read command. A malicious controller can request data for the read request even though R2T should apply only to writes.

3

Can this be detected from normal host logs or command failures?

Not reliably from the behavior described. The read command completes normally and nothing is logged, even when host memory contents are disclosed.

4

What is the required remediation?

Apply a kernel update containing the fix that rejects an R2T for any request that is not a write. The referenced stable commits provide the relevant fixes.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203