[PATCH net] rxrpc: Take write lock when publishing the initial RxGK key

[PATCH net] rxrpc: Take write lock when publishing the initial RxGK key

[Chengfeng Ye]

rxgk_rekey() updates the transport-key ring under security_use_lock,
and rxgk_get_key() takes a reference under the corresponding read
lock.  The initial publication in rxgk_init_connection_security()
writes conn->rxgk.enctype and conn->rxgk.keys[] without the write
lock.

On a client connection, a second sendmsg can observe
RXRPC_CONN_CLIENT through a lockless load of conn->state, skip
rxrpc_init_client_conn_security(), and call rxgk_get_key() without
ever acquiring security_lock.  Because the initializer never took
the write lock, the reader's read lock provides neither exclusion
nor a matching acquire-release pair.

Concurrent RxGK key consumers were observed in a two-sender
workload.  KCSAN reported:

  BUG: KCSAN: data-race in rxgk_get_key / rxgk_secure_packet

  write to 0xffff8aef4023c318 of 8 bytes by task 1968 on cpu 0:
   rxgk_secure_packet+0x46c/0x820
   rxrpc_send_data+0x562/0x1a20
   rxrpc_do_sendmsg+0x976/0xa80
   rxrpc_sendmsg+0x20f/0x2a0

  read to 0xffff8aef4023c318 of 8 bytes by task 1969 on cpu 1:
   rxgk_get_key+0x209/0x5e0
   rxgk_alloc_txbuf+0xa4/0x2a0
   rxrpc_send_data+0x8e2/0x1a20
   rxrpc_do_sendmsg+0x976/0xa80
   rxrpc_sendmsg+0x20f/0x2a0

  value changed: 0x7fffffffffffffff -> 0x7fffffffffffffee

That report is on the key context's byte counter rather than the
initial publication, but it shows that lookup and secured transmit
already overlap on the same connection.

Take security_use_lock for writing while publishing the initial
enctype and transport key, matching the locking used when rekeying.

Signed-off-by: Chengfeng Ye <nicoyip.dev@gmail.com>
---
 net/rxrpc/rxgk.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/rxrpc/rxgk.c b/net/rxrpc/rxgk.c
index 77a67ace1d24..b49221f57f67 100644
--- a/net/rxrpc/rxgk.c
+++ b/net/rxrpc/rxgk.c
@@ -251,8 +251,10 @@ static int rxgk_init_connection_security(struct rxrpc_connection *conn,
 					 GFP_NOFS);
 	if (IS_ERR(gk))
 		return PTR_ERR(gk);
+	write_lock(&conn->security_use_lock);
 	conn->rxgk.enctype = gk->krb5->etype;
 	conn->rxgk.keys[gk->key_number & 3] = gk;
+	write_unlock(&conn->security_use_lock);
 
 	switch (conn->security_level) {
 	case RXRPC_SECURITY_PLAIN:
-- 
2.43.0

Re: [PATCH net] rxrpc: Take write lock when publishing the initial RxGK key

[Simon Horman]

On Mon, Aug 24, 2026 at 11:02:20PM +0800, Chengfeng Ye wrote:
> rxgk_rekey() updates the transport-key ring under security_use_lock,
> and rxgk_get_key() takes a reference under the corresponding read
> lock.  The initial publication in rxgk_init_connection_security()
> writes conn->rxgk.enctype and conn->rxgk.keys[] without the write
> lock.
> 
> On a client connection, a second sendmsg can observe
> RXRPC_CONN_CLIENT through a lockless load of conn->state, skip
> rxrpc_init_client_conn_security(), and call rxgk_get_key() without
> ever acquiring security_lock.  Because the initializer never took
> the write lock, the reader's read lock provides neither exclusion
> nor a matching acquire-release pair.
> 
> Concurrent RxGK key consumers were observed in a two-sender
> workload.  KCSAN reported:
> 
>   BUG: KCSAN: data-race in rxgk_get_key / rxgk_secure_packet
> 
>   write to 0xffff8aef4023c318 of 8 bytes by task 1968 on cpu 0:
>    rxgk_secure_packet+0x46c/0x820
>    rxrpc_send_data+0x562/0x1a20
>    rxrpc_do_sendmsg+0x976/0xa80
>    rxrpc_sendmsg+0x20f/0x2a0
> 
>   read to 0xffff8aef4023c318 of 8 bytes by task 1969 on cpu 1:
>    rxgk_get_key+0x209/0x5e0
>    rxgk_alloc_txbuf+0xa4/0x2a0
>    rxrpc_send_data+0x8e2/0x1a20
>    rxrpc_do_sendmsg+0x976/0xa80
>    rxrpc_sendmsg+0x20f/0x2a0
> 
>   value changed: 0x7fffffffffffffff -> 0x7fffffffffffffee
> 
> That report is on the key context's byte counter rather than the
> initial publication, but it shows that lookup and secured transmit
> already overlap on the same connection.
> 
> Take security_use_lock for writing while publishing the initial
> enctype and transport key, matching the locking used when rekeying.
> 

I think a Fixes tag is needed here, citing the patch where
this problem first manifested.

You can simply post it in response to this email.
But if you do re-post for some other reason note that
there should not be a blank line between the Fixes and
Signed-off-by tags (or between any other tags).

> Signed-off-by: Chengfeng Ye <nicoyip.dev@gmail.com>

...

Re: [PATCH net] rxrpc: Take write lock when publishing the initial RxGK key

[Chengfeng Ye]

On Thu, Sep 3, 2026 at 5:07 PM Simon Horman <horms@kernel.org> wrote:
>
> On Mon, Aug 24, 2026 at 11:02:20PM +0800, Chengfeng Ye wrote:
> > rxgk_rekey() updates the transport-key ring under security_use_lock,
> > and rxgk_get_key() takes a reference under the corresponding read
> > lock.  The initial publication in rxgk_init_connection_security()
> > writes conn->rxgk.enctype and conn->rxgk.keys[] without the write
> > lock.
> >
> > On a client connection, a second sendmsg can observe
> > RXRPC_CONN_CLIENT through a lockless load of conn->state, skip
> > rxrpc_init_client_conn_security(), and call rxgk_get_key() without
> > ever acquiring security_lock.  Because the initializer never took
> > the write lock, the reader's read lock provides neither exclusion
> > nor a matching acquire-release pair.
> >
> > Concurrent RxGK key consumers were observed in a two-sender
> > workload.  KCSAN reported:
> >
> >   BUG: KCSAN: data-race in rxgk_get_key / rxgk_secure_packet
> >
> >   write to 0xffff8aef4023c318 of 8 bytes by task 1968 on cpu 0:
> >    rxgk_secure_packet+0x46c/0x820
> >    rxrpc_send_data+0x562/0x1a20
> >    rxrpc_do_sendmsg+0x976/0xa80
> >    rxrpc_sendmsg+0x20f/0x2a0
> >
> >   read to 0xffff8aef4023c318 of 8 bytes by task 1969 on cpu 1:
> >    rxgk_get_key+0x209/0x5e0
> >    rxgk_alloc_txbuf+0xa4/0x2a0
> >    rxrpc_send_data+0x8e2/0x1a20
> >    rxrpc_do_sendmsg+0x976/0xa80
> >    rxrpc_sendmsg+0x20f/0x2a0
> >
> >   value changed: 0x7fffffffffffffff -> 0x7fffffffffffffee
> >
> > That report is on the key context's byte counter rather than the
> > initial publication, but it shows that lookup and secured transmit
> > already overlap on the same connection.
> >
> > Take security_use_lock for writing while publishing the initial
> > enctype and transport key, matching the locking used when rekeying.
> >
>
> I think a Fixes tag is needed here, citing the patch where
> this problem first manifested.
>
> You can simply post it in response to this email.
> But if you do re-post for some other reason note that
> there should not be a blank line between the Fixes and
> Signed-off-by tags (or between any other tags).
>
> > Signed-off-by: Chengfeng Ye <nicoyip.dev@gmail.com>
>
> ...

Thanks for the review.

Fixes: 9d1d2b59341f ("rxrpc: rxgk: Implement the yfs-rxgk security
class (GSSAPI)")

Best regards,
Chengfeng