CVE-2026-52995

What it actually does

This is a local information disclosure flaw in the Linux kernel Reliable Datagram Sockets (RDS) implementation. When RDS connection information is requested for InfiniBand/RDMA transports, the kernel can copy an only partially initialized stack buffer back to user space. On kernels without automatic stack zeroing, an unprivileged local user may receive stale kernel stack bytes, including kernel text/data pointers and other memory residues. The primary technical risk is exposure of kernel memory layout information, which can weaken kernel address space layout randomization (KASLR) and support follow-on local privilege escalation exploits.

Why it matters to the business

An attacker who already has local code execution on a Linux system may be able to extract sensitive kernel memory artifacts that make other kernel attacks easier and more reliable. This is most relevant for multi-user systems, shared compute platforms, container hosts, high-performance computing environments, and systems with RDS/RDMA functionality enabled or loadable. By itself, this issue is not expected to provide remote compromise or direct privilege escalation, but it can materially reduce the difficulty of chaining another kernel vulnerability. It is not listed in CISA KEV, is not known to be used in ransomware campaigns, and currently has low EPSS, so remediation should be prioritized based on local-user exposure and whether RDS/RDMA is enabled.

How an attack unfolds

A local unprivileged attacker first obtains the ability to run code on the target Linux system. They then create an AF_RDS socket and select the InfiniBand/RDMA transport. If physical RDMA is unavailable, a software RoCE setup may be sufficient where permitted by the system configuration. The attacker binds the socket to a local address and attempts to communicate with a peer address, causing an RDS connection object to be created in a connecting state. The attacker then requests RDS InfiniBand connection information with getsockopt using RDS_INFO_IB_CONNECTIONS. Vulnerable kernels return a connection-info structure containing fields deliberately populated by the kernel mixed with uninitialized stack bytes. The attacker repeats the operation to collect leaked kernel pointers or other stack residues, then uses those values to bypass address randomization or improve reliability of a separate kernel exploit chain.

How to fix it

Upgrade to a Linux kernel that includes the RDS fix which zeroes the per-item info buffer before visitor callbacks in rds_for_each_conn_info() and rds_walk_conn_path_info(). If consuming vendor kernels, apply the relevant distribution security update when available rather than relying only on upstream version numbers. Where immediate patching is not possible, reduce exposure by disabling or preventing loading of the RDS kernel module if it is not required, restricting local shell/code execution, limiting access to RDMA/soft-RoCE configuration, and enforcing kernel hardening options such as stack auto-initialization where supported. Systems built with CONFIG_INIT_STACK_ALL_ZERO reduce the practical leakage described, but patching remains the correct fix.

How to confirm the fix worked

Confirm the running kernel contains the fix from the vendor or upstream stable branch. Validate that RDS is either patched or not available by checking loaded modules and kernel configuration for RDS support. On systems where RDS is required, use a controlled test environment to verify that calls requesting RDS InfiniBand connection information no longer return non-zero stale data in fields that should be zero or explicitly initialized for non-up connections. Also confirm any compensating control, such as module blocklisting, persists across reboot and prevents unprivileged use of AF_RDS where RDS is not needed.

Typical attack path

1. Gain local ability to execute code as an unprivileged user on a Linux host.
2. Open an AF_RDS socket and configure it to use the RDS InfiniBand/RDMA transport.
3. Bind the socket to a local address on an RDMA-capable interface or software RoCE-capable interface.
4. Trigger creation of an RDS connection object by attempting to send traffic to a peer address.
5. Call getsockopt with SOL_RDS and RDS_INFO_IB_CONNECTIONS to retrieve RDS connection information.
6. Extract uninitialized stack bytes from the returned structure, potentially including kernel pointers.
7. Use the leaked kernel addresses or memory artifacts to assist a follow-on kernel exploit.

How to detect it

Post-exploitation detection is difficult because the vulnerable operation is a legitimate local socket option call and is not usually logged by default. Focus on evidence of unexpected RDS/RDMA use from local processes, especially on systems that do not normally use RDS. Useful sources include auditd or eBPF syscall telemetry for socket(AF_RDS), setsockopt/getsockopt involving SOL_RDS, kernel module load logs, systemd-journald, dmesg, shell history, process execution telemetry, and endpoint detection logs. Look for unexpected loading of rds, rds_rdma, ib_core, rdma_rxe, or related modules; creation of software RoCE interfaces; local binaries repeatedly opening AF_RDS sockets; and suspicious tooling that references RDS_INFO_IB_CONNECTIONS. If exploitation is suspected, also search for follow-on local privilege escalation indicators such as kernel crash logs, abnormal oops/panic messages, attempts to read kernel symbols, or execution of exploit-like binaries in temporary directories.

• AF_RDS
• SO_RDS_TRANSPORT
• SOL_RDS
• RDS_INFO_IB_CONNECTIONS
• RDS_INFO_CONNECTIONS
• socket(AF_RDS
• getsockopt(SOL_RDS
• setsockopt(SOL_RDS
• /proc/net/rds
• /sys/module/rds
• /sys/module/rds_rdma
• rds.ko
• rds_rdma.ko
• rdma_rxe
• /sys/module/rdma_rxe
• modprobe rds
• modprobe rds_rdma
• modprobe rdma_rxe
• rxe_cfg
• rdma link add
• CONFIG_RDS
• CONFIG_RDS_RDMA
• CONFIG_INIT_STACK_ALL_ZERO

What your security team should do

• Inventory Linux systems with RDS enabled, RDMA/InfiniBand support, or soft-RoCE capability, prioritizing shared and multi-user hosts.
• Apply vendor kernel security updates that include the RDS buffer-zeroing fix.
• If RDS is not operationally required, disable or blocklist the RDS module and verify it cannot be autoloaded by unprivileged activity.
• Prioritize remediation on container hosts, HPC clusters, build systems, research platforms, and any environment where untrusted users can run local code.
• Review kernel hardening posture, including stack initialization options, kernel pointer exposure controls, and restrictions on unprivileged module loading or RDMA configuration.
• Monitor for suspicious local use of AF_RDS sockets, RDS getsockopt calls, and unexpected loading of RDS or RDMA-related modules.
• Treat any confirmed exploitation as a potential precursor to local privilege escalation and investigate for chained kernel exploit activity.