[rds-devel] [External] : Re: rds: possible cross netns leak via RDS_INFO_* getsockopt

[Allison Henderson]

On Tue, 2026-05-05 at 08:37 +0000, Xie Maoyi wrote:
> Hi all,
> 
> We are not sure whether what we observed is a real bug or
> intended behaviour. We would appreciate your view.
> 
> In net/rds/info.c, rds_info_getsockopt() dispatches to handlers
> registered in rds_info_funcs[]. Each handler reads a global list
> that is not pernet:
> 
>   rds_sock_info / rds6_sock_info        -> rds_sock_list
>   rds_tcp_tc_info / rds6_tcp_tc_info    -> rds_tcp_tc_list
>   rds_conn_info / rds6_conn_info        -> rds_conn_hash[]
> 
> None of those filter by the caller's netns. rds_info_getsockopt()
> also has no netns or capable() check. rds_create() has no
> capable() check either. So AF_RDS is reachable from an
> unprivileged user namespace.
> 
> Our reading is that an unprivileged caller in a fresh user_ns
> plus netns can read RDS state from init_net. We see this in
> practice on the latest net tree.
> 
> The fields that come back include:
> 
>   RDS_INFO_SOCKETS:     bound addr, port, sock inode of every
>                         RDS socket on the host
>   RDS_INFO_TCP_SOCKETS: peer addr, port, last_sent_nxt,
>                         last_expected_una, last_seen_una of
>                         every rds-tcp connection on the host
>   RDS_INFO_CONNECTIONS: peer addr, port, cp_next_tx_seq,
>                         cp_next_rx_seq of every RDS connection
> 
> A small reproducer is attached as poc_rds_info.c. With rds and
> rds_tcp loaded, the steps are:
> 
>   modprobe rds
>   modprobe rds_tcp
>   ./poc_rds_info
> 
> The PoC binds an AF_RDS socket in init_net to 127.0.0.1:4242 as
> root. It then enters a fresh user_ns plus netns and opens AF_RDS
> there. The attacker side reads RDS_INFO_SOCKETS and sees the
> init_net socket. A run log is attached as poc_verification.log.
> 
> We are not sure if this counts as a bug or is by design. The
> RDS_INFO_* interface looks diagnostic. It may be expected to be
> host wide. On the other hand, AF_RDS is reachable from an
> unprivileged user namespace, which is what surprised us.
> 
> Could you let us know whether you consider this worth fixing? If
> yes, we have a draft patch that gates rds_info_getsockopt() to
> init_net. We can send it once you confirm the direction.
> 
> Thanks for your time.
> 
> Maoyi Xie and Praveen Kakkolangara
> 
> Maoyi Xie
> Nanyang Technological University
> https://maoyixie.com/


Hi Xie,

Thanks for looking into this.  I think your findings are valid, diagnostic or debug tools shouldn't allow callers
visibility into another netns.  Note though that while the ib transport is limited to init_net the tcp transport is not
(see rds_set_transport()).  So one gate in rds_info_getsockopt would incorrectly filter netns that a tcp connection
might have legitimate visibility to. So the fix would need a filter in each of the three handlers you've identified,
where we can compare the netns of the socket to the netns of the entry (or c_net for connection paths), and only copy
info for relevant sockets instead of every entry in the respective global list/hash.

Allison

> ________________________________
> 
> CONFIDENTIALITY: This email is intended solely for the person(s) named and may be confidential and/or privileged. If you are not the intended recipient, please delete it, notify us and do not copy, use, or disclose its contents.
> Towards a sustainable earth: Print only when necessary. Thank you.