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

[Simon Horman <horms@kernel.org>]

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>

...