In rxrpc_setsockopt(), the code checks 'rx->key' when handling the
RXRPC_SECURITY_KEYRING option. However, this appears to be a logic error.
The code should be checking 'rx->securities' to determine if a keyring
has already been defined for the socket.

Currently, if a user calls setsockopt(RXRPC_SECURITY_KEYRING) multiple
times on the same socket, the check 'if (rx->key)' fails to block
subsequent calls because 'rx->key' has not been defined by the function.
This results in a reference count leak on the keyring.

This patch changes the check to 'rx->securities' to correctly identify
if the socket security keyring has already been configured, returning -EINVAL
on subsequent attempts.

Before the patch:

It shows the keyring reference counter elevated.

$ cat /proc/keys | grep AFSkeys1
27aca8ae I--Q--- 24469721 perm 3f010000  1000  1000 keyring   AFSkeys1: empty
$

After the patch:

The keyring reference counter remains stable and subsequent calls return an error:

$ ./poc
setsockopt: Invalid argument
$

Fixes: 17926a7 ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both")
Signed-off-by: Anderson Nascimento <anderson@allelesecurity.com>
---
 net/rxrpc/af_rxrpc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/rxrpc/af_rxrpc.c b/net/rxrpc/af_rxrpc.c
index 0c2c68c4b07e..add72ac61f73 100644
--- a/net/rxrpc/af_rxrpc.c
+++ b/net/rxrpc/af_rxrpc.c
@@ -663,7 +663,7 @@ static int rxrpc_setsockopt(struct socket *sock, int level, int optname,
 
 		case RXRPC_SECURITY_KEYRING:
 			ret = -EINVAL;
-			if (rx->key)
+			if (rx->securities)
 				goto error;
 			ret = -EISCONN;
 			if (rx->sk.sk_state != RXRPC_UNBOUND)
-- 
2.53.0

On Fri, Mar 13, 2026 at 10:23:26AM -0300, Anderson Nascimento wrote:
> In rxrpc_setsockopt(), the code checks 'rx->key' when handling the
> RXRPC_SECURITY_KEYRING option. However, this appears to be a logic error.
> The code should be checking 'rx->securities' to determine if a keyring
> has already been defined for the socket.
> 
> Currently, if a user calls setsockopt(RXRPC_SECURITY_KEYRING) multiple
> times on the same socket, the check 'if (rx->key)' fails to block
> subsequent calls because 'rx->key' has not been defined by the function.
> This results in a reference count leak on the keyring.
> 
> This patch changes the check to 'rx->securities' to correctly identify
> if the socket security keyring has already been configured, returning -EINVAL
> on subsequent attempts.
> 
> Before the patch:
> 
> It shows the keyring reference counter elevated.
> 
> $ cat /proc/keys | grep AFSkeys1
> 27aca8ae I--Q--- 24469721 perm 3f010000  1000  1000 keyring   AFSkeys1: empty
> $
> 
> After the patch:
> 
> The keyring reference counter remains stable and subsequent calls return an error:
> 
> $ ./poc
> setsockopt: Invalid argument
> $
> 
> Fixes: 17926a7 ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both")

nit: Please use 12 (or more if needed to avoid a collision) bytes
     for the hash in Fixes tags.

> Signed-off-by: Anderson Nascimento <anderson@allelesecurity.com>

...

Simon Horman <horms@kernel.org> wrote:

> > Fixes: 17926a7 ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both")
> 
> nit: Please use 12 (or more if needed to avoid a collision) bytes
>      for the hash in Fixes tags.

I fixed this when I posted my collection of rxrpc patches, including this one.

David

On Thu, Mar 19, 2026 at 04:55:53PM +0000, David Howells wrote:
> Simon Horman <horms@kernel.org> wrote:
> 
> > > Fixes: 17926a7 ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both")
> > 
> > nit: Please use 12 (or more if needed to avoid a collision) bytes
> >      for the hash in Fixes tags.
> 
> I fixed this when I posted my collection of rxrpc patches, including this one.

Thanks David,

Sorry for not noticing that.