CVE-2026-68335: rds: drop incoming messages that cross network namespace boundaries

From: Greg Kroah-Hartman <[email protected]>

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

rds: drop incoming messages that cross network namespace boundaries

rds_find_bound() looks up the destination socket using a global
rhashtable keyed solely on (addr, port, scope_id).  Network namespaces
are not part of the key, so a sender in netns A can deliver an incoming
message (inc) to a socket that lives in a different netns B.

When this happens, inc->i_conn points to an rds_connection whose c_net
is netns A, but the receiving rs lives in netns B.  Once the child
process that created netns A exits, cleanup_net() calls
rds_loop_exit_net() -> rds_loop_kill_conns() -> rds_conn_destroy(),
freeing that connection.  If the survivor socket in netns B still holds
the inc, any subsequent dereference of inc->i_conn is a use-after-free.

There are two dangerous sites in rds_clear_recv_queue():
  1. inc->i_conn->c_lcong (offset 88 of freed rds_connection, size 200)
     read via rds_recv_rcvbuf_delta() -- confirmed by KASAN.
  2. inc->i_conn->c_trans->inc_free(inc) (function pointer at offset 80)
     called via rds_inc_put() when the inc refcount reaches zero -- same
     race window, potential call-through-freed-object primitive.

The bug is reachable from unprivileged user namespaces
(CLONE_NEWUSER + CLONE_NEWNET), available since Linux 3.8.

Fix this by rejecting the delivery in rds_recv_incoming() when the
socket returned by rds_find_bound() belongs to a different network
namespace than the connection that carried the message.  Use the
existing rds_conn_net() / sock_net() helpers and net_eq() for the
comparison.

The Linux kernel CVE team has assigned CVE-2026-68335 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 4.18 with commit c809195f5523dd4d09403bbb1c9732d548aa0d1e and fixed in 6.6.148 with commit 1e2e2d9806944fe485824d617c8b7c78116c22db
	Issue introduced in 4.18 with commit c809195f5523dd4d09403bbb1c9732d548aa0d1e and fixed in 6.12.101 with commit cfb3ce07b705e486e022a2f2b1242b48f13981ff
	Issue introduced in 4.18 with commit c809195f5523dd4d09403bbb1c9732d548aa0d1e and fixed in 6.18.42 with commit 9591042533140dfe6608d9344806d567dcd39d02
	Issue introduced in 4.18 with commit c809195f5523dd4d09403bbb1c9732d548aa0d1e and fixed in 7.1.6 with commit 0f8690e3869109cd5803ccb400889d20a0b54e0e
	Issue introduced in 4.18 with commit c809195f5523dd4d09403bbb1c9732d548aa0d1e and fixed in 7.2-rc5 with commit 5521ae71e32a8069ed4ca6e792179dc57bc43ab2
	Issue introduced in 4.17.19 with commit c827073c95fde388bc65fe5227f944eaf859b9f0

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-68335
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	net/rds/recv.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/1e2e2d9806944fe485824d617c8b7c78116c22db
	https://git.kernel.org/stable/c/cfb3ce07b705e486e022a2f2b1242b48f13981ff
	https://git.kernel.org/stable/c/9591042533140dfe6608d9344806d567dcd39d02
	https://git.kernel.org/stable/c/0f8690e3869109cd5803ccb400889d20a0b54e0e
	https://git.kernel.org/stable/c/5521ae71e32a8069ed4ca6e792179dc57bc43ab2