[bpf-ci-bot] sk_psock_backlog refcount mismatch causes spurious kernel_splats CI failures

[kernel-patches-review-bot]

Summary

sk_psock_backlog() uses sk_psock_get(psock->sk) to take a reference before processing queued skbs, but this looks up whatever psock is currently attached to the socket (sk->sk_user_data), which can differ from the psock running the backlog. On the refcount underflow path, this triggers a refcount_warn_saturate WARNING that the new kernel_splats CI check correctly flags, failing otherwise-passing test runs.

Failure Details

• Test / Component: sockmap_redir — all subtests pass, but kernel_splats check detects a WARNING in dmesg
• Frequency: Rare/intermittent — observed in 1 of 12 runs examined (Aug 24, 2026); same PR passing clean Aug 21
• Failure mode: Refcount underflow (REFCOUNT_SUB_UAF) in psock backlog worker, caught by dmesg scanning
• Affected architectures: x86_64 (observed); likely all architectures
• CI runs observed:
  • https://github.com/kernel-patches/bpf/actions/runs/32685005965 (FAIL: kernel_splats)
  • https://github.com/kernel-patches/bpf/actions/runs/32526561449 (same PR, PASS: no splat)

Root Cause Analysis

The race exists in net/core/skmsg.c:sk_psock_backlog() (line 693):

if (!sk_psock_get(psock->sk))   /* BUG: may increment WRONG psock's refcnt */
    return;
...
sk_psock_put(psock->sk, psock); /* decrements THIS psock's refcnt */

sk_psock_get(psock->sk) calls sk_psock(sk) which reads rcu_dereference(sk->sk_user_data). If the socket was re-mapped between sk_psock_drop() (which sets sk_user_data = NULL under sk_callback_lock) and sk_psock_stop() (which clears SK_PSOCK_TX_ENABLED AFTER releasing the lock), a new psock can be attached to the socket in that window.

Race timeline:

1. Old psock (P1) refcount → 0, triggering sk_psock_drop()
2. sk_psock_drop() sets sk_user_data = NULL (under lock), then releases lock
3. Another CPU creates new psock P2 for same socket via sk_psock_init() (acquires same lock, sees NULL, creates P2)
4. P1's backlog fires: SK_PSOCK_TX_ENABLED still set (step 3b sk_psock_stop() hasn't run yet)
5. sk_psock_get(P1->sk) → finds P2 via sk_user_data → increments P2->refcnt
6. sk_psock_put(P1->sk, P1) → decrements P1->refcnt (already 0) → UNDERFLOW!

This was introduced by commit 8259eb0e06d8 ("bpf, sockmap: Avoid using sk_socket after free when sending") which added the sk_psock_get(psock->sk) call to synchronize with sock_map_close().

Proposed Fix

Replace sk_psock_get(psock->sk) with refcount_inc_not_zero(&psock->refcnt) to directly increment the backlog's own psock refcount. This:

• Eliminates the mismatch: always increments/decrements the same psock
• Preserves the synchronization property: while refcount > 0, sk_psock_drop() hasn't been called, so sk_user_data still points to this psock, meaning sock_map_close()'s sk_psock_get(sk) will find it and call cancel_delayed_work_sync()
• Correctly fails (returns false) if refcount is already 0, triggering early return

See output/0001-bpf-sockmap-Fix-psock-refcount-mismatch-in-sk_psock_backlog.patch.

Impact

Without the fix, the kernel_splats CI check will intermittently fail sockmap_redir test runs despite all tests passing. This creates misleading CI signal that developers must manually investigate and dismiss. The underlying refcount underflow also indicates a potential use-after-free if the psock is freed while backlog is still processing.

References

• Commit 8259eb0e06d8 ("bpf, sockmap: Avoid using sk_socket after free when sending") — introduced the vulnerable pattern
• Michal Luczaj's sockmap refcount cleanup series (Aug 2026): https://lore.kernel.org/bpf/20260813-sockmap-lookup-get-ref-v1-0-31f5d55f44ac@rbox.co/ — related but different issue (socket refcnt in lookup, not psock refcnt in backlog)
• kernel_splats check: github/libbpf/ci/run-vmtest/check-kernel-splats.sh

[kernel-patches-review-bot]

0001-bpf-sockmap-Fix-psock-refcount-mismatch-in-sk_psock_backlog.patch

From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: BPF CI Bot <bot+bpf-ci@kernel.org>
Date: Sun, 24 Aug 2026 00:00:00 +0000
Subject: [PATCH bpf] bpf, sockmap: Fix psock refcount mismatch in
 sk_psock_backlog()

sk_psock_backlog() takes a psock reference at the start via
sk_psock_get(psock->sk), but this function looks up whatever psock is
currently attached to the socket through sk->sk_user_data. If the socket
was re-mapped (old psock detached, new psock attached) between
sk_psock_drop() clearing sk_user_data and sk_psock_stop() clearing
SK_PSOCK_TX_ENABLED, the lookup can return a *different* psock.

The backlog then increments the new psock's refcnt but decrements the
old psock's refcnt at the end via sk_psock_put(), causing a refcount
underflow (REFCOUNT_SUB_UAF) on the old psock:

  WARNING: lib/refcount.c:28 at refcount_warn_saturate+0x84/0xd0
  Workqueue: events sk_psock_backlog
  Call Trace:
   sk_psock_backlog+0xe43/0xee0
   process_scheduled_works+0x819/0x1180
   worker_thread+0x840/0xca0
   kthread+0x319/0x3e0

Fix this by using refcount_inc_not_zero() directly on the backlog's own
psock rather than performing a socket-based lookup. This ensures the
same psock's refcount is incremented and decremented, while preserving
the synchronization with sock_map_close(): as long as the refcount is
above zero, sk_psock_drop() has not been called, so sk_user_data still
points to this psock and sock_map_close()'s sk_psock_get() will find it
and call cancel_delayed_work_sync().

Fixes: 8259eb0e06d8 ("bpf, sockmap: Avoid using sk_socket after free when sending")
Generated-by: BPF CI Bot (claude-opus-4-6-v1) <bot+bpf-ci@kernel.org>
Signed-off-by: BPF CI Bot <bot+bpf-ci@kernel.org>
---
 net/core/skmsg.c | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/net/core/skmsg.c b/net/core/skmsg.c
index 2521b643fa05..aad002bab983 100644
--- a/net/core/skmsg.c
+++ b/net/core/skmsg.c
@@ -685,12 +685,15 @@ static void sk_psock_backlog(struct work_struct *work)
 	if (!sk_psock_test_state(psock, SK_PSOCK_TX_ENABLED))
 		return;

-	/* Increment the psock refcnt to synchronize with close(fd) path in
-	 * sock_map_close(), ensuring we wait for backlog thread completion
-	 * before sk_socket freed. If refcnt increment fails, it indicates
-	 * sock_map_close() completed with sk_socket potentially already freed.
+	/* Increment the psock refcnt so sock_map_close() sees the psock via
+	 * sk_psock_get() and waits for this work to finish via
+	 * cancel_delayed_work_sync(). Use refcount_inc_not_zero() directly on
+	 * this psock rather than sk_psock_get(psock->sk): the latter looks up
+	 * whatever psock is currently attached to the socket, which may differ
+	 * from ours if the socket was re-mapped after sk_psock_drop() detached
+	 * this psock but before sk_psock_stop() cleared TX_ENABLED.
 	 */
-	if (!sk_psock_get(psock->sk))
+	if (!refcount_inc_not_zero(&psock->refcnt))
 		return;
 	mutex_lock(&psock->work_mutex);
 	while ((skb = skb_peek(&psock->ingress_skb))) {
--
2.43.0

[kernel-patches-review-bot]

0002-ci-allowlist-sk_psock_backlog-refcount-warning.patch

From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: BPF CI Bot <bot+bpf-ci@kernel.org>
Date: Sun, 24 Aug 2026 00:00:00 +0000
Subject: [PATCH vmtest] ci: Allowlist sk_psock_backlog refcount warning until
 kernel fix lands

The sockmap psock backlog worker has a race condition where
sk_psock_get(psock->sk) can find a different psock than the one running
the backlog, causing a refcount_warn_saturate WARNING. This is a
pre-existing kernel bug, not introduced by any specific PR.

Allowlist the specific warning pattern to prevent spurious CI failures
while the kernel fix (using refcount_inc_not_zero(&psock->refcnt)
directly) is reviewed and merged upstream.

Delete this entry once the fix reaches the CI kernel.

Generated-by: BPF CI Bot (claude-opus-4-6-v1) <bot+bpf-ci@kernel.org>
Signed-off-by: BPF CI Bot <bot+bpf-ci@kernel.org>
---
 ci/vmtest/configs/SPLAT_ALLOWLIST | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/ci/vmtest/configs/SPLAT_ALLOWLIST b/ci/vmtest/configs/SPLAT_ALLOWLIST
index ...... 100644
--- a/ci/vmtest/configs/SPLAT_ALLOWLIST
+++ b/ci/vmtest/configs/SPLAT_ALLOWLIST
@@ -19,3 +19,8 @@ WARNING: Unprivileged eBPF is enabled
 # Delete this entry once that fix reaches the CI kernel.
 BUG: KASAN: stack-out-of-bounds in (stack_trace_consume_entry|filter_irq_stacks)\+

+# sk_psock_backlog has a race where sk_psock_get(psock->sk) can find a different
+# psock if the socket was re-mapped, causing a refcount underflow WARNING. Kernel
+# fix: use refcount_inc_not_zero(&psock->refcnt) directly.
+# Delete this entry once the fix reaches the CI kernel.
+WARNING:.* at refcount_warn_saturate\+.* sk_psock_backlog\+
--
2.43.0