CVE-2026-52995

NONECVSS 0.0
0.0
EchelonGraph verdictMonitorLow exploitation likelihood right now — keep watching.
  • No confirmed exploitation signals yet
CISA-KEV: Not listedEPSS: 0%CVSS: Exploit: NoneExposed: 0

No vendor fix yet — apply a workaround or compensating control (WAF / firewall / segmentation) and watch for a patch.

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

CVSS v3
EG Score
0.0(none)
EPSS
7.4%
KEV
Not listed

Published

June 24, 2026

Last Modified

June 24, 2026

Vendor Advisories for CVE-2026-52995(1)

These vendors published their own advisory mentioning this CVE — often with vendor-specific remediation steps + affected product lists not in NVD.

Data Freshness Timeline

(refreshed 10× in last 7d / 21× in last 30d)

Each row is a source pipeline that fetched or updated this CVE on that date, with what changed. For example, "NVD update" means NVD published or revised its analysis for this CVE; "MITRE cvelistV5" means we ingested or refreshed it from the CNA feed. Most recent first.

  1. 2026-07-06 19:10 UTCGHSA enrichment
  2. 2026-07-06 16:27 UTCEPSS rescore
  3. 2026-07-06 16:27 UTCEPSS rescore
  4. 2026-07-05 02:31 UTCEPSS rescore
  5. 2026-07-05 02:30 UTCEPSS rescore
  6. 2026-07-04 06:31 UTCEPSS rescore
  7. 2026-07-03 18:57 UTCGHSA enrichment
  8. 2026-07-01 15:07 UTCEPSS rescore
  9. 2026-06-30 23:22 UTCEPSS rescore
  10. 2026-06-30 18:46 UTCGHSA enrichment
  11. 2026-06-29 14:06 UTCEPSS rescore
  12. 2026-06-29 14:06 UTCEPSS rescore
  13. 2026-06-28 14:07 UTCEPSS rescore
  14. 2026-06-28 04:56 UTCEPSS rescore
  15. 2026-06-28 04:56 UTCEPSS rescore
  16. 2026-06-27 18:35 UTCEG score recompute
  17. 2026-06-27 18:35 UTCGHSA enrichment
  18. 2026-06-27 03:08 UTCEPSS rescore
  19. 2026-06-25 13:49 UTCEPSS rescore
  20. 2026-06-24 18:24 UTCEG score recompute
  21. 2026-06-24 18:02 UTCNVD updatefirst tracked

Frequently asked(4)

What is CVE-2026-52995?
CVE-2026-52995 is a none vulnerability published on June 24, 2026. In the Linux kernel, the following vulnerability has been resolved: net/rds: zero per-item info buffer before handing it to visitors rdsforeachconninfo() and rdswalkconnpathinfo() both hand a caller-allocated on-stack u64 buffer to a per-connection visitor and then copy the full item_len bytes back…
When was CVE-2026-52995 disclosed?
CVE-2026-52995 was first published in the National Vulnerability Database on June 24, 2026. EchelonGraph re-ingests CVE updates from NVD on a 2-hour cycle, so this page reflects the latest published state.
Is CVE-2026-52995 actively exploited?
CVE-2026-52995 is not currently on CISA's Known Exploited Vulnerabilities catalog. FIRST EPSS estimates a 7.4% percentile likelihood of exploitation in the next 30 days — higher percentiles indicate greater predicted risk.
How do I remediate CVE-2026-52995?
Patch to the fixed version published by the affected vendor. Where vendor advisories exist for CVE-2026-52995, EchelonGraph cross-links them in the Vendor Advisories panel below — those typically contain the canonical remediation steps, fixed version numbers, and any vendor-specific mitigations.

Dependency Blast Radius

Explore the affected products and dependency analysis for CVE-2026-52995

Explore →

Is Your Infrastructure Affected by CVE-2026-52995?

EchelonGraph automatically scans your cloud infrastructure and maps CVE exposure using blast radius analysis.