From: Chengfeng Ye <nicoyip.dev@gmail.com>
To: David Howells <dhowells@redhat.com>,
Marc Dionne <marc.dionne@auristor.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>
Cc: linux-afs@lists.infradead.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
Chengfeng Ye <nicoyip.dev@gmail.com>,
stable@vger.kernel.org
Subject: [PATCH net] rxrpc: Prevent reusing service connections marked for reaping
Date: Sun, 27 Sep 2026 14:44:34 +0800 [thread overview]
Message-ID: <20260927064434.3692113-1-nicoyip.dev@gmail.com> (raw)
The service connection reaper changes conn->active from 0 to -1 before
unpublishing an idle connection. The I/O thread can have already found
that connection and acquired an input reference. If it then allocates a
new call, rxrpc_alloc_incoming_call() unconditionally increments
conn->active, changing -1 back to 0. This violates the reaper's final
assertion and can panic the kernel:
I/O thread Reaper
Look up conn and take input ref
Set active from 0 to -1
Allocate an incoming call
Increment active from -1 to 0
Assert active == -1
The kernel reported:
kernel BUG at net/rxrpc/conn_object.c:465!
Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
Workqueue: krxrpcd rxrpc_service_connection_reaper
RIP: 0010:rxrpc_service_connection_reaper+0x768/0xbc0
Call Trace:
process_one_work+0x5f2/0xf20
worker_thread+0x46e/0xda0
kthread+0x2b2/0x390
ret_from_fork+0x36e/0x5a0
Use atomic_inc_unless_negative() before taking the call's connection
reference. If reaping won the race, leave the activity count untouched
and return through the existing BUSY rejection path without consuming a
preallocated call. The caller's input reference keeps the connection
live during this check. If call allocation wins, the positive activity
count prevents the reaper from claiming the connection.
Fixes: 3cec055c5695 ("rxrpc: Don't hold a ref for connection workqueue")
Cc: stable@vger.kernel.org
Signed-off-by: Chengfeng Ye <nicoyip.dev@gmail.com>
---
net/rxrpc/call_accept.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/rxrpc/call_accept.c b/net/rxrpc/call_accept.c
index 47824120f1da..87bc3af2208b 100644
--- a/net/rxrpc/call_accept.c
+++ b/net/rxrpc/call_accept.c
@@ -299,8 +299,9 @@ static struct rxrpc_call *rxrpc_alloc_incoming_call(struct rxrpc_sock *rx,
rxrpc_see_connection(conn, rxrpc_conn_see_new_service_conn);
rxrpc_new_incoming_connection(rx, conn, sec, skb);
} else {
+ if (!atomic_inc_unless_negative(&conn->active))
+ return NULL;
rxrpc_get_connection(conn, rxrpc_conn_get_service_conn);
- atomic_inc(&conn->active);
}
/* And now we can allocate and set up a new call */
--
2.43.0
next reply other threads:[~2026-09-27 6:45 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-27 6:44 Chengfeng Ye [this message]
2026-10-08 8:01 ` [PATCH net] rxrpc: Prevent reusing service connections marked for reaping Chengfeng Ye
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260927064434.3692113-1-nicoyip.dev@gmail.com \
--to=nicoyip.dev@gmail.com \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-afs@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marc.dionne@auristor.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.