CVE-2026-97476

Received Received - Intake

Information Disclosure in Linux Kernel RDS Module

Publication date: 2026-09-24

Last updated on: 2026-10-03

Assigner: kernel.org

Description

In the Linux kernel, the following vulnerability has been resolved: rds: filter RDS_INFO_* getsockopt by caller's netns The RDS_INFO_* family of getsockopt(2) options reads several file-scope global lists that are not per-netns: rds_sock_info / rds6_sock_info, rds_sock_inc_info / rds6_sock_inc_info -> rds_sock_list rds_tcp_tc_info / rds6_tcp_tc_info -> rds_tcp_tc_list rds_conn_info / rds6_conn_info, rds_conn_message_info_cmn (for the *_SEND_MESSAGES and *_RETRANS_MESSAGES variants), rds_for_each_conn_info (for RDS_INFO_IB_CONNECTIONS) -> rds_conn_hash[] The handlers do not filter by the caller's network namespace. rds_info_getsockopt() has no netns or capable() check, and rds_create() has no capable() check, so AF_RDS is reachable from an unprivileged user namespace. As a result, an unprivileged caller in a fresh user_ns plus netns can read the bound address and sock inode of every RDS socket on the host, the peer address of incoming messages on every RDS socket on the host, the peer address and TCP sequence numbers of every rds-tcp connection on the host, and the peer address and RDS sequence numbers of every RDS connection on the host. The rds-tcp transport is reachable from a non-initial netns (see rds_set_transport()), so a one-shot init_net gate at rds_info_getsockopt() would deny legitimate per-netns visibility to rds-tcp callers. Instead, filter at each handler by comparing the netns of the caller's socket to the netns of the list entry, or to rds_conn_net(conn) for connection paths. Only copy entries whose netns matches the caller. Counters (RDS_INFO_COUNTERS) are aggregate statistics and remain global. Reproducer (KASAN VM, rds and rds_tcp loaded): an AF_RDS socket binds 127.0.0.1:4242 in init_net as root. A child process enters a fresh user_ns plus netns and opens AF_RDS there, then calls getsockopt(SOL_RDS, RDS_INFO_SOCKETS). Before this change, the child sees the init_net socket. After this change, the child sees zero entries. Drop the rds_sock_count, rds_tcp_tc_count, and rds6_tcp_tc_count globals. v2 used them for the size precheck and lens->nr; v3 replaced the precheck with a per-ns count from a first pass over the list, so the globals have no remaining readers. The matching increments and decrements in rds_create()/rds_destroy_sock() and rds_tcp_set_callbacks()/rds_tcp_restore_callbacks() go away with them. Reported by the kernel test robot under clang W=1.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published

2026-09-24

Last Modified

2026-10-03

Generated

2026-10-15

AI Q&A

2026-09-25

EPSS Evaluated

2026-10-13

NVD

CVE-2026-97476

EUVD

EUVD-2026-86074

Affected Vendors & Products

Vendor	Product	Version / Range
linux	linux_kernel	*

Helpful Resources

Exploitability

CWE

KEV

CWE ID	Description
CWE-UNKNOWN

Attack-Flow Graph

Executive Summary

This vulnerability in the Linux kernel allows unprivileged users in a fresh user namespace with a new network namespace to read sensitive information from RDS sockets on the host. The issue occurs because the RDS_INFO_* getsockopt options do not filter results by the caller's network namespace, exposing details like bound addresses, socket inodes, peer addresses, and TCP sequence numbers.

Detection Guidance

This vulnerability can be detected by checking for unauthorized access to RDS socket information. Use commands like 'ss -tulnp' to inspect RDS sockets and 'netstat -tulnp' to verify active connections. Look for unexpected sockets bound to 127.0.0.1 or unusual network namespaces.

Impact Analysis

An attacker could exploit this to gather information about RDS sockets and connections on the host system, potentially aiding further attacks. This includes learning about active connections, peer addresses, and sequence numbers, which could be used to infer system activity or target specific services.

Compliance Impact

This vulnerability allows unprivileged users in a fresh user namespace with a new network namespace to read sensitive socket and connection information from the host, including bound addresses, peer addresses, and sequence numbers. This could potentially expose personal or sensitive data, which may violate compliance requirements under GDPR (data protection) or HIPAA (health information privacy) if such data is inadvertently disclosed.

Mitigation Strategies

Apply the latest Linux kernel patches to address this issue. Ensure the RDS module is updated and verify that network namespace isolation is correctly enforced. Restrict unprivileged user namespace access if not required for operations.

Hi! I’m here to help you understand CVE-2026-97476. Ask me anything about the vulnerability, its impact, or mitigation strategies.

0/70