CVE-2026-52995: net/rds: zero per-item info buffer before handing it to visitors
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 itemlen bytes back to user space via rdsinfocopy() regardless of how much of the buffer the visitor actually wrote.
rdsibconninfovisitor() and rds6ibconninfovisitor() only write a subset of their output struct when the underlying rdsconnection is not in state RDSCONNUP (src/dst addr, tos, sl and the two GIDs via explicit memsets). Several u32 fields (maxsendwr, maxrecvwr, maxsendsge, rdmamrmax, rdmamrsize, cacheallocs) and the 2-byte alignment hole between sl and cacheallocs remain as whatever stack contents preceded the visitor call and are then memcpytouser()'d out to user space.
struct rdsinfordmaconnection and struct rds6infordmaconnection are the only rdsinfo structs in include/uapi/linux/rds.h that are not marked attribute((packed)), so they have a real alignment hole. The other info visitors (rdsconninfovisitor, rds6conninfovisitor, rdstcptcinfo, ...) 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 CONFIGINITSTACKALLZERO=y: a local unprivileged user opens AFRDS, sets SORDSTRANSPORT=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 rdsconnection in the global hash in RDSCONNCONNECTING), then calls getsockopt(SOLRDS, RDSINFOIBCONNECTIONS). 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 (maxsendwr) 48..55 7f 37 b5 81 ff ff ff ff kernel pointer (rdmamrmax) 56..59 01 00 08 00 rdmamrsize (garbage) 60..61 00 00 tos, sl 62..63 00 00 alignment padding 64..67 18 00 00 00 cacheallocs (garbage)
Fix by zeroing the per-item buffer in both rdsforeachconninfo() and rdswalkconnpathinfo() 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
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernel (net/rds)to a version that resolves this vulnerability.Patch net/rds: zero per-item info buffer before handing it to visitors - Configuration
Enable CONFIG_INIT_STACK_ALL_ZERO in the kernel configuration to ensure per-item stack buffers used by RDS info visitors are initialized to zero (the issue reproduces when CONFIG_INIT_STACK_ALL_ZERO=y is not set).
Linux kernel RDS module CONFIG_INIT_STACK_ALL_ZERO = y
Event History
Frequently Asked Questions
Who can exploit this issue?
An attacker needs local access and low-level privileges sufficient to invoke the affected RDS information interfaces. The exposed data is copied from kernel stack memory to user space.
What information can be disclosed?
When an RDS connection is not in the RDS_CONN_UP state, several RDMA connection fields and a two-byte alignment hole may contain uninitialized kernel stack contents. The affected fields include max_send_wr, max_recv_wr, max_send_sge, rdma_mr_max, rdma_mr_size, and cache_allocs.
Are all RDS information structures affected?
No. The issue is identified in struct rds_info_rdma_connection and struct rds6_info_rdma_connection, the only listed rds_info structures that are not packed and therefore contain a real alignment hole. The described incomplete initialization occurs in the IPv4 and IPv6 IB connection information visitors.