net/core/sock.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
A reproducible rcuref - imbalanced put() warning is observed under
IPv6 L2TP (pppol2tp) traffic with blackhole routes, indicating an
imbalance in dst reference counting for routes cached in
sk->sk_dst_cache and pointing to a subtle lifetime/synchronization
issue between the helpers that validate and drop cached dst entries.
rcuref - imbalanced put()
WARNING: CPU: 0 PID: 899 at lib/rcuref.c:266 rcuref_put_slowpath+0x1ce/0x240 lib/rcuref.c:266
Modules linked in:
CPSocket connected tcp:127.0.0.1:48148,server=on <-> 127.0.0.1:33750
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:rcuref_put_slowpath+0x1ce/0x240 lib/rcuref.c:266
Call Trace:
<TASK>
__rcuref_put include/linux/rcuref.h:97 [inline]
rcuref_put include/linux/rcuref.h:153 [inline]
dst_release+0x291/0x310 net/core/dst.c:167
__sk_dst_check+0x2d4/0x350 net/core/sock.c:604
__inet6_csk_dst_check net/ipv6/inet6_connection_sock.c:76 [inline]
inet6_csk_route_socket+0x6ed/0x10c0 net/ipv6/inet6_connection_sock.c:104
inet6_csk_xmit+0x12f/0x740 net/ipv6/inet6_connection_sock.c:121
l2tp_xmit_queue net/l2tp/l2tp_core.c:1214 [inline]
l2tp_xmit_core net/l2tp/l2tp_core.c:1309 [inline]
l2tp_xmit_skb+0x1404/0x1910 net/l2tp/l2tp_core.c:1325
pppol2tp_sendmsg+0x3ca/0x550 net/l2tp/l2tp_ppp.c:302
sock_sendmsg_nosec net/socket.c:729 [inline]
__sock_sendmsg net/socket.c:744 [inline]
____sys_sendmsg+0xab2/0xc70 net/socket.c:2609
___sys_sendmsg+0x11d/0x1c0 net/socket.c:2663
__sys_sendmmsg+0x188/0x450 net/socket.c:2749
__do_sys_sendmmsg net/socket.c:2778 [inline]
__se_sys_sendmmsg net/socket.c:2775 [inline]
__x64_sys_sendmmsg+0x98/0x100 net/socket.c:2775
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0x64/0x140 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x76/0x7e
RIP: 0033:0x7fe6960ec719
</TASK>
The race occurs between the lockless UDPv6 transmit path
(udpv6_sendmsg() -> sk_dst_check()) and the locked L2TP/pppol2tp
transmit path (pppol2tp_sendmsg() -> l2tp_xmit_skb() ->
... -> inet6_csk_xmit() → __sk_dst_check()), when both handle
the same obsolete dst from sk->sk_dst_cache: the UDPv6 side takes
an extra reference and atomically steals and releases the cached
dst, while the L2TP side, using a stale cached pointer, still
calls dst_release() on it, and together these updates produce
an extra final dst_release() on that dst, triggering
rcuref - imbalanced put().
The Race Condition:
Initial:
sk->sk_dst_cache = dst
ref(dst) = 1
Thread 1: sk_dst_check() Thread 2: __sk_dst_check()
------------------------ ----------------------------
sk_dst_get(sk):
rcu_read_lock()
dst = rcu_dereference(sk->sk_dst_cache)
rcuref_get(dst) succeeds
rcu_read_unlock()
// ref = 2
dst = __sk_dst_get(sk)
// reads same dst from sk_dst_cache
// ref still = 2 (no extra get)
[both see dst obsolete & check() == NULL]
sk_dst_reset(sk):
old = xchg(&sk->sk_dst_cache, NULL)
// old = dst
dst_release(old)
// drop cached ref
// ref: 2 -> 1
RCU_INIT_POINTER(sk->sk_dst_cache, NULL)
// cache already NULL after xchg
dst_release(dst)
// ref: 1 -> 0
dst_release(dst)
// tries to drop its own ref after final put
// rcuref_put_slowpath() -> "rcuref - imbalanced put()"
Fix this by making the locked __sk_dst_check() use the same “steal
from sk->sk_dst_cache” pattern as the lockless path: instead of
clearing the cache and releasing a potentially stale local dst,
it atomically exchanges sk->sk_dst_cache with NULL and only calls
dst_release() on the pointer returned from that exchange. This
guarantees that, for any given cached dst, at most one of the
competing helpers (sk_dst_check() or __sk_dst_check()) can acquire
and drop the cache-owned reference, so they can no longer
double-release the same entry; the atomic operation runs only in the
obsolete path and should not affect the main path.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Fixes: d14730b8e911 ("ipv6: use RCU in inet6_csk_xmit()")
Signed-off-by: Mikhail Lobanov <m.lobanov@rosa.ru>
---
net/core/sock.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/core/sock.c b/net/core/sock.c
index dc03d4b5909a..7f356f976627 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -607,14 +607,15 @@ INDIRECT_CALLABLE_DECLARE(struct dst_entry *ipv4_dst_check(struct dst_entry *,
struct dst_entry *__sk_dst_check(struct sock *sk, u32 cookie)
{
struct dst_entry *dst = __sk_dst_get(sk);
+ struct dst_entry *old_dst;
if (dst && READ_ONCE(dst->obsolete) &&
INDIRECT_CALL_INET(dst->ops->check, ip6_dst_check, ipv4_dst_check,
dst, cookie) == NULL) {
sk_tx_queue_clear(sk);
WRITE_ONCE(sk->sk_dst_pending_confirm, 0);
- RCU_INIT_POINTER(sk->sk_dst_cache, NULL);
- dst_release(dst);
+ old_dst = unrcu_pointer(xchg(&sk->sk_dst_cache, RCU_INITIALIZER(NULL)));
+ dst_release(old_dst);
return NULL;
}
--
2.47.2
On Wed, Nov 12, 2025 at 3:39 AM Mikhail Lobanov <m.lobanov@rosa.ru> wrote:
>
> A reproducible rcuref - imbalanced put() warning is observed under
> IPv6 L2TP (pppol2tp) traffic with blackhole routes, indicating an
> imbalance in dst reference counting for routes cached in
> sk->sk_dst_cache and pointing to a subtle lifetime/synchronization
> issue between the helpers that validate and drop cached dst entries.
>
> rcuref - imbalanced put()
> WARNING: CPU: 0 PID: 899 at lib/rcuref.c:266 rcuref_put_slowpath+0x1ce/0x240 lib/rcuref.c:266
> Modules linked in:
> CPSocket connected tcp:127.0.0.1:48148,server=on <-> 127.0.0.1:33750
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
> RIP: 0010:rcuref_put_slowpath+0x1ce/0x240 lib/rcuref.c:266
>
> Call Trace:
> <TASK>
> __rcuref_put include/linux/rcuref.h:97 [inline]
> rcuref_put include/linux/rcuref.h:153 [inline]
> dst_release+0x291/0x310 net/core/dst.c:167
> __sk_dst_check+0x2d4/0x350 net/core/sock.c:604
> __inet6_csk_dst_check net/ipv6/inet6_connection_sock.c:76 [inline]
> inet6_csk_route_socket+0x6ed/0x10c0 net/ipv6/inet6_connection_sock.c:104
> inet6_csk_xmit+0x12f/0x740 net/ipv6/inet6_connection_sock.c:121
> l2tp_xmit_queue net/l2tp/l2tp_core.c:1214 [inline]
> l2tp_xmit_core net/l2tp/l2tp_core.c:1309 [inline]
> l2tp_xmit_skb+0x1404/0x1910 net/l2tp/l2tp_core.c:1325
> pppol2tp_sendmsg+0x3ca/0x550 net/l2tp/l2tp_ppp.c:302
> sock_sendmsg_nosec net/socket.c:729 [inline]
> __sock_sendmsg net/socket.c:744 [inline]
> ____sys_sendmsg+0xab2/0xc70 net/socket.c:2609
> ___sys_sendmsg+0x11d/0x1c0 net/socket.c:2663
> __sys_sendmmsg+0x188/0x450 net/socket.c:2749
> __do_sys_sendmmsg net/socket.c:2778 [inline]
> __se_sys_sendmmsg net/socket.c:2775 [inline]
> __x64_sys_sendmmsg+0x98/0x100 net/socket.c:2775
> do_syscall_x64 arch/x86/entry/common.c:52 [inline]
> do_syscall_64+0x64/0x140 arch/x86/entry/common.c:83
> entry_SYSCALL_64_after_hwframe+0x76/0x7e
> RIP: 0033:0x7fe6960ec719
> </TASK>
>
> The race occurs between the lockless UDPv6 transmit path
> (udpv6_sendmsg() -> sk_dst_check()) and the locked L2TP/pppol2tp
> transmit path (pppol2tp_sendmsg() -> l2tp_xmit_skb() ->
> ... -> inet6_csk_xmit() → __sk_dst_check()), when both handle
> the same obsolete dst from sk->sk_dst_cache: the UDPv6 side takes
> an extra reference and atomically steals and releases the cached
> dst, while the L2TP side, using a stale cached pointer, still
> calls dst_release() on it, and together these updates produce
> an extra final dst_release() on that dst, triggering
> rcuref - imbalanced put().
>
> The Race Condition:
>
> Initial:
> sk->sk_dst_cache = dst
> ref(dst) = 1
>
> Thread 1: sk_dst_check() Thread 2: __sk_dst_check()
> ------------------------ ----------------------------
> sk_dst_get(sk):
> rcu_read_lock()
> dst = rcu_dereference(sk->sk_dst_cache)
> rcuref_get(dst) succeeds
> rcu_read_unlock()
> // ref = 2
>
> dst = __sk_dst_get(sk)
> // reads same dst from sk_dst_cache
> // ref still = 2 (no extra get)
>
> [both see dst obsolete & check() == NULL]
>
> sk_dst_reset(sk):
> old = xchg(&sk->sk_dst_cache, NULL)
> // old = dst
> dst_release(old)
> // drop cached ref
> // ref: 2 -> 1
>
> RCU_INIT_POINTER(sk->sk_dst_cache, NULL)
> // cache already NULL after xchg
> dst_release(dst)
> // ref: 1 -> 0
>
> dst_release(dst)
> // tries to drop its own ref after final put
> // rcuref_put_slowpath() -> "rcuref - imbalanced put()"
>
> Fix this by making the locked __sk_dst_check() use the same “steal
> from sk->sk_dst_cache” pattern as the lockless path: instead of
> clearing the cache and releasing a potentially stale local dst,
> it atomically exchanges sk->sk_dst_cache with NULL and only calls
> dst_release() on the pointer returned from that exchange. This
> guarantees that, for any given cached dst, at most one of the
> competing helpers (sk_dst_check() or __sk_dst_check()) can acquire
> and drop the cache-owned reference, so they can no longer
> double-release the same entry; the atomic operation runs only in the
> obsolete path and should not affect the main path.
>
> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
>
> Fixes: d14730b8e911 ("ipv6: use RCU in inet6_csk_xmit()")
> Signed-off-by: Mikhail Lobanov <m.lobanov@rosa.ru>
> ---
> net/core/sock.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/net/core/sock.c b/net/core/sock.c
> index dc03d4b5909a..7f356f976627 100644
> --- a/net/core/sock.c
> +++ b/net/core/sock.c
> @@ -607,14 +607,15 @@ INDIRECT_CALLABLE_DECLARE(struct dst_entry *ipv4_dst_check(struct dst_entry *,
> struct dst_entry *__sk_dst_check(struct sock *sk, u32 cookie)
> {
> struct dst_entry *dst = __sk_dst_get(sk);
> + struct dst_entry *old_dst;
>
> if (dst && READ_ONCE(dst->obsolete) &&
> INDIRECT_CALL_INET(dst->ops->check, ip6_dst_check, ipv4_dst_check,
> dst, cookie) == NULL) {
> sk_tx_queue_clear(sk);
> WRITE_ONCE(sk->sk_dst_pending_confirm, 0);
> - RCU_INIT_POINTER(sk->sk_dst_cache, NULL);
> - dst_release(dst);
> + old_dst = unrcu_pointer(xchg(&sk->sk_dst_cache, RCU_INITIALIZER(NULL)));
> + dst_release(old_dst);
> return NULL;
> }
>
This is not a correct fix.
Please take a look at sk_dst_check() vs __sk_dst_check() , and why we have both.
(Same for __sk_dst_get() vs sk_dst_get())
inet6_csk_xmit() is reserved for sockets holding their socket lock.
Please fix l2tp instead.
Thank you.
© 2016 - 2026 Red Hat, Inc.