Skip to main content
VulnerabilityPublished Updated

CVE-2026-52995: Linux kernel · net/rds: zero per-item info buffer before handing it to visitors

Affects Linux kernelSource CVE Database V5

0
Compare

Not known to be exploited · fixed in c88eb7e8d8397a8c1db59c425332c5a30b2a1682 : update Linux kernel when convenient.

Data as of 6 Nov 2026, 16:49 UTC

Severity
Unrated

Rated by Threat Radar · No CVSS score from NVD or the CNA

Thin evidence

One scorer or none
CISA SSVC
Exploitation
No evidence of active exploitation and no public proof of concept
Automatable
Attackers cannot reliably automate steps 1–4 of the kill chain
Technical impact
Limited control over the software or limited information exposure

CISA SSVC assessment, 2026-11-06.

Patch
Available – fixed in c88eb7e8d8397a8c1db59c425332c5a30b2a1682, c7cb9eed8215a790f052f49cdccf577720d2bb62, b6ba93a7b71ed443c9843eb12d27ed86f1e52694 +5

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 24 Jun 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponized: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 6 Nov 2026.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ ec16227e14141e4fd7ae76354c09dadfe2449d9e, < c88eb7e8d8397a8c1db59c425332c5a30b2a1682
Fixed in
  • c88eb7e8d8397a8c1db59c425332c5a30b2a1682
LinuxLinuxAffected
  • ≥ ec16227e14141e4fd7ae76354c09dadfe2449d9e, < c7cb9eed8215a790f052f49cdccf577720d2bb62
Fixed in
  • c7cb9eed8215a790f052f49cdccf577720d2bb62
LinuxLinuxAffected
  • ≥ ec16227e14141e4fd7ae76354c09dadfe2449d9e, < b6ba93a7b71ed443c9843eb12d27ed86f1e52694
Fixed in
  • b6ba93a7b71ed443c9843eb12d27ed86f1e52694
LinuxLinuxAffected
  • ≥ ec16227e14141e4fd7ae76354c09dadfe2449d9e, < 81651e9d7dea1c048d2952f57632a042931d7b43
Fixed in
  • 81651e9d7dea1c048d2952f57632a042931d7b43
LinuxLinuxAffected
  • ≥ ec16227e14141e4fd7ae76354c09dadfe2449d9e, < 912ba2e5704fdb8bc5decda96dfc1a57838f0099
Fixed in
  • 912ba2e5704fdb8bc5decda96dfc1a57838f0099
LinuxLinuxAffected
  • ≥ ec16227e14141e4fd7ae76354c09dadfe2449d9e, < 0797b2e6901827694aa9c34c4c72118c8c97fba1
Fixed in
  • 0797b2e6901827694aa9c34c4c72118c8c97fba1

Description

In the Linux kernel, the following vulnerability has been resolved: net/rds: zero per-item info buffer before handing it to visitors rds_for_each_conn_info() and rds_walk_conn_path_info() both hand a caller-allocated on-stack u64 buffer to a per-connection visitor and then copy the full item_len bytes back to user space via rds_info_copy() regardless of how much of the buffer the visitor actually wrote. rds_ib_conn_info_visitor() and rds6_ib_conn_info_visitor() only write a subset of their output struct when the underlying rds_connection is not in state RDS_CONN_UP (src/dst addr, tos, sl and the two GIDs via explicit memsets). Several u32 fields (max_send_wr, max_recv_wr, max_send_sge, rdma_mr_max, rdma_mr_size, cache_allocs) and the 2-byte alignment hole between sl and cache_allocs remain as whatever stack contents preceded the visitor call and are then memcpy_to_user()'d out to user space. struct rds_info_rdma_connection and struct rds6_info_rdma_connection are the only rds_info_* structs in include/uapi/linux/rds.h that are not marked __attribute__((packed)), so they have a real alignment hole. The other info visitors (rds_conn_info_visitor, rds6_conn_info_visitor, rds_tcp_tc_info, ...) write all fields of their packed output struct today and are not known to be vulnerable, but a future visitor that adds a conditional write-path would have the same bug. Reproduction on a kernel built without CONFIG_INIT_STACK_ALL_ZERO=y: a local unprivileged user opens AF_RDS, sets SO_RDS_TRANSPORT=IB, binds to a local address on an RDMA-capable netdev (rxe soft-RoCE on any netdev is sufficient), sendto()'s any peer on the same subnet (fails cleanly but installs an rds_connection in the global hash in RDS_CONN_CONNECTING), then calls getsockopt(SOL_RDS, RDS_INFO_IB_CONNECTIONS). The returned 68-byte item contains 26 bytes of stack garbage including kernel text/data pointers: 0..7 0a 63 00 01 0a 63 00 02 src=10.99.0.1 dst=10.99.0.2 8..39 00 ... gids (memset-zeroed) 40..47 e0 92 a3 81 ff ff ff ff kernel pointer (max_send_wr) 48..55 7f 37 b5 81 ff ff ff ff kernel pointer (rdma_mr_max) 56..59 01 00 08 00 rdma_mr_size (garbage) 60..61 00 00 tos, sl 62..63 00 00 alignment padding 64..67 18 00 00 00 cache_allocs (garbage) Fix by zeroing the per-item buffer in both rds_for_each_conn_info() and rds_walk_conn_path_info() before invoking the visitor. This covers the IPv4/IPv6 IB visitors and hardens all current and future visitors against the same class of bug. No functional change for visitors that fully populate their output. Changes in v2: - retarget at the net tree (subject prefix "[PATCH net v2]", net/rds: prefix in the title) - pick up Reviewed-by tags from Sharath Srinivasan and Allison Henderson

References

Community reviews

Loading reviews…