Linux RDMA/rtrs-srv: unvalidated usr_len from the wire underflows data_len into an out-of-bounds length

CVSS 9.8CVE-2026-97413Firmware, BMC & network fabriccurated

Impact

usr_len comes straight off the wire (le16_to_cpu) and is used to compute data_len = off - usr_len with no check that usr_len <= off. A client that sends usr_len > off wraps data_len to a huge size_t, which is handed to the rdma_ev callback as a memory length and drives an out-of-bounds access in the server. This is a remote, pre-auth memory-corruption primitive against any node running the RTRS transport server - typically the storage side of an RNBD/RTRS block-over-RDMA setup on an InfiniBand or RoCE fabric that also carries tenant traffic. A crash takes the storage target down for every client attached to it; worse outcomes are plausible given the attacker controls the length.

Who can reach it

Any host that can open an RTRS session to the server over the RDMA fabric. No authentication. Only affects nodes with the rtrs-srv module in use.

What to do

Apply the stable-kernel fix (three stable branches carry it) and reboot the affected storage/target nodes. If you do not run RTRS/RNBD, confirm the module is not loaded and there is nothing to do. Restricting which hosts can reach the RTRS listener on the fabric is a partial mitigation while you schedule the reboot.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-97413 https://git.kernel.org/stable/c/24ad03bfeda05fca04c56677e57fd3d6bc3e9978 https://git.kernel.org/stable/c/c76e9123ab91a903396d26e6ab1b5caae5c6b149

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.