Description

In the Linux kernel, the following vulnerability has been resolved: rds: tcp: hold the RCU lock across ipv6_chk_addr() in rds_tcp_laddr_check() rds_tcp_laddr_check() looks up a scoped IPv6 interface with dev_get_by_index_rcu(), drops the RCU read-side lock, and only then passes the bare struct net_device * into ipv6_chk_addr(). dev_get_by_index_rcu() only keeps the device alive within the same RCU read-side section. After rcu_read_unlock(), a concurrent RTM_DELLINK can free the net_device; ipv6_chk_addr() then dereferences the stale pointer in __ipv6_chk_addr_and_flags() (e.g. l3mdev_master_dev_rcu(dev)), reading freed memory. Keep the RCU read-side lock held across the ipv6_chk_addr() call instead of dropping it right after the lookup, so the device cannot be freed while it is in use. BUG: KASAN: slab-use-after-free in __ipv6_chk_addr_and_flags (... net/ipv6/addrconf.c:1998) Read of size 8 at addr ffff8880106ec000 by task exploit/153 Call Trace: ... kasan_report (mm/kasan/report.c:595) __ipv6_chk_addr_and_flags (... net/ipv6/addrconf.c:1998) ipv6_chk_addr (net/ipv6/addrconf.c:2031 net/ipv6/addrconf.c:1972) rds_tcp_laddr_check (net/rds/tcp.c:370) rds_bind (net/rds/bind.c:248) __sys_bind (net/socket.c:1920) __x64_sys_bind (net/socket.c:1956) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-08-15T13:18:01.790Z",
  "pubdate": "2026-08-15T13:18:01.790Z",
  "executiveSummary": "A use-after-free vulnerability exists in the Linux kernel's Reliable Datagram Sockets (RDS) TCP implementation, specifically within the rds_tcp_laddr_check() function. The flaw is caused by improper management of the Read-Copy Update (RCU) read-side critical section when handling IPv6 network devices. An attacker capable of interacting with local sockets or triggering specific network interface deletion events can exploit this vulnerability to cause kernel memory corruption, potentially leading to local privilege escalation or a denial of service via kernel panic. The issue arises when a net_device structure is freed concurrently while a stale pointer is still being dereferenced during an ipv6_chk_addr() call. Exploitation requires the ability to execute code on the target system to trigger the vulnerable socket bind operations and race against interface teardown sequences.",
  "technicalDetails": "The vulnerability resides in the net/rds/tcp.c source file of the Linux kernel, specifically within the rds_tcp_laddr_check() function. During the local address check for RDS over TCP using IPv6, the kernel performs a lookup for a scoped IPv6 interface using dev_get_by_index_rcu(). This function retrieves a pointer to a struct net_device while inside an RCU read-side critical section. However, the original implementation prematurely drops the RCU read-side lock via rcu_read_unlock() immediately after the lookup, passing the bare struct net_device * pointer unprotected into ipv6_chk_addr(). Because the RCU read-side critical section has ended, synchronization guarantees are lost. A concurrent network interface deletion event, such as an RTM_DELLINK netlink message, can cause the kernel to free the net_device structure via the networking subsystem teardown path. Subsequently, when ipv6_chk_addr() executes and invokes internal routines like __ipv6_chk_addr_and_flags()—which calls helpers such as l3mdev_master_dev_rcu(dev)—it dereferences the dangling pointer to read fields from the already-freed slab memory. This results in a classic slab-use-after-free condition. An attacker can trigger this attack flow by initiating a bind system call on an RDS socket (rds_bind), which implicitly invokes rds_tcp_laddr_check() while simultaneously or preemptively racing an RTM_DELLINK command to destroy the underlying network device. Successful exploitation leads to KASAN-detected slab-use-after-free reports, unstable kernel execution, potential arbitrary read/write primitives depending on heap layout state, and subsequent system crashes or kernel panics."
}