When creating a client call in rxrpc_alloc_client_call(), the code obtains a
reference to the key. If rxrpc_init_client_call_security() fails (e.g., due
to key invalidation), the function returns an error and destroys the call,
but fails to release the reference to the key.
This leads to a reference count leak, preventing the key from being
garbage collected.
Before the patch
It shows the key reference counter elevated.
$ cat /proc/keys | grep afs@54321
1bffe9cd I--Q--i 8053480 4169w 3b010000 1000 1000 rxrpc afs@54321: ka
$
After the patch
The invalidated key is removed when the code exits
$ cat /proc/keys | grep afs@54321
$
Fixes: f3441d4 ("rxrpc: Copy client call parameters into rxrpc_call earlier")
Signed-off-by: Anderson Nascimento <anderson@allelesecurity.com>
---
net/rxrpc/call_object.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/rxrpc/call_object.c b/net/rxrpc/call_object.c
index 918f41d97a2f..fbfcc611a2c4 100644
--- a/net/rxrpc/call_object.c
+++ b/net/rxrpc/call_object.c
@@ -227,6 +227,7 @@ static struct rxrpc_call *rxrpc_alloc_client_call(struct rxrpc_sock *rx,
ret = rxrpc_init_client_call_security(call);
if (ret < 0) {
+ key_put(call->key);
rxrpc_prefail_call(call, RXRPC_CALL_LOCAL_ERROR, ret);
rxrpc_put_call(call, rxrpc_call_put_discard_error);
return ERR_PTR(ret);
--
2.53.0
Hi Anderson,
I think the patch can be done better as the attached - and this takes care of
another leak also. Can you recheck your test?
Thanks,
David
---
commit 8e931ee13f267b814c0b668e9f52867b5239fed6
Author: Anderson Nascimento <anderson@allelesecurity.com>
Date: Fri Mar 13 10:23:27 2026 -0300
rxrpc: Fix key reference count leak from call->key
When creating a client call in rxrpc_alloc_client_call(), the code obtains
a reference to the key. This is never cleaned up and gets leaked when the
call is destroyed.
Fix this by freeing call->key in rxrpc_destroy_call().
Before the patch, it shows the key reference counter elevated:
$ cat /proc/keys | grep afs@54321
1bffe9cd I--Q--i 8053480 4169w 3b010000 1000 1000 rxrpc afs@54321: ka
$
After the patch, the invalidated key is removed when the code exits:
$ cat /proc/keys | grep afs@54321
$
Fixes: f3441d4125fc ("rxrpc: Copy client call parameters into rxrpc_call earlier")
Signed-off-by: Anderson Nascimento <anderson@allelesecurity.com>
Co-developed-by: David Howells <dhowells@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Marc Dionne <marc.dionne@auristor.com>
cc: Eric Dumazet <edumazet@google.com>
cc: "David S. Miller" <davem@davemloft.net>
cc: Jakub Kicinski <kuba@kernel.org>
cc: Paolo Abeni <pabeni@redhat.com>
cc: Simon Horman <horms@kernel.org>
cc: linux-afs@lists.infradead.org
cc: netdev@vger.kernel.org
cc: stable@kernel.org
diff --git a/net/rxrpc/call_object.c b/net/rxrpc/call_object.c
index 918f41d97a2f..8d874ea428ff 100644
--- a/net/rxrpc/call_object.c
+++ b/net/rxrpc/call_object.c
@@ -694,6 +694,7 @@ static void rxrpc_destroy_call(struct work_struct *work)
rxrpc_put_bundle(call->bundle, rxrpc_bundle_put_call);
rxrpc_put_peer(call->peer, rxrpc_peer_put_call);
rxrpc_put_local(call->local, rxrpc_local_put_call);
+ key_put(call->key);
call_rcu(&call->rcu, rxrpc_rcu_free_call);
}
On Wed, Mar 18, 2026 at 7:20 PM David Howells <dhowells@redhat.com> wrote:
>
> Hi Anderson,
>
> I think the patch can be done better as the attached - and this takes care of
> another leak also. Can you recheck your test?
It fixes the issue. You can proceed with the patch. Thank you.
>
> Thanks,
> David
> ---
> commit 8e931ee13f267b814c0b668e9f52867b5239fed6
> Author: Anderson Nascimento <anderson@allelesecurity.com>
> Date: Fri Mar 13 10:23:27 2026 -0300
>
> rxrpc: Fix key reference count leak from call->key
>
> When creating a client call in rxrpc_alloc_client_call(), the code obtains
> a reference to the key. This is never cleaned up and gets leaked when the
> call is destroyed.
>
> Fix this by freeing call->key in rxrpc_destroy_call().
>
> Before the patch, it shows the key reference counter elevated:
>
> $ cat /proc/keys | grep afs@54321
> 1bffe9cd I--Q--i 8053480 4169w 3b010000 1000 1000 rxrpc afs@54321: ka
> $
>
> After the patch, the invalidated key is removed when the code exits:
>
> $ cat /proc/keys | grep afs@54321
> $
>
> Fixes: f3441d4125fc ("rxrpc: Copy client call parameters into rxrpc_call earlier")
> Signed-off-by: Anderson Nascimento <anderson@allelesecurity.com>
> Co-developed-by: David Howells <dhowells@redhat.com>
> Signed-off-by: David Howells <dhowells@redhat.com>
> cc: Marc Dionne <marc.dionne@auristor.com>
> cc: Eric Dumazet <edumazet@google.com>
> cc: "David S. Miller" <davem@davemloft.net>
> cc: Jakub Kicinski <kuba@kernel.org>
> cc: Paolo Abeni <pabeni@redhat.com>
> cc: Simon Horman <horms@kernel.org>
> cc: linux-afs@lists.infradead.org
> cc: netdev@vger.kernel.org
> cc: stable@kernel.org
>
> diff --git a/net/rxrpc/call_object.c b/net/rxrpc/call_object.c
> index 918f41d97a2f..8d874ea428ff 100644
> --- a/net/rxrpc/call_object.c
> +++ b/net/rxrpc/call_object.c
> @@ -694,6 +694,7 @@ static void rxrpc_destroy_call(struct work_struct *work)
> rxrpc_put_bundle(call->bundle, rxrpc_bundle_put_call);
> rxrpc_put_peer(call->peer, rxrpc_peer_put_call);
> rxrpc_put_local(call->local, rxrpc_local_put_call);
> + key_put(call->key);
> call_rcu(&call->rcu, rxrpc_rcu_free_call);
> }
>
>
--
Anderson Nascimento
Allele Security Intelligence
https://www.allelesecurity.com
Hi David,
That sounds better. I will test it and let you know. Thanks.
On Wed, Mar 18, 2026 at 7:20 PM David Howells <dhowells@redhat.com> wrote:
>
> Hi Anderson,
>
> I think the patch can be done better as the attached - and this takes care of
> another leak also. Can you recheck your test?
>
> Thanks,
> David
> ---
> commit 8e931ee13f267b814c0b668e9f52867b5239fed6
> Author: Anderson Nascimento <anderson@allelesecurity.com>
> Date: Fri Mar 13 10:23:27 2026 -0300
>
> rxrpc: Fix key reference count leak from call->key
>
> When creating a client call in rxrpc_alloc_client_call(), the code obtains
> a reference to the key. This is never cleaned up and gets leaked when the
> call is destroyed.
>
> Fix this by freeing call->key in rxrpc_destroy_call().
>
> Before the patch, it shows the key reference counter elevated:
>
> $ cat /proc/keys | grep afs@54321
> 1bffe9cd I--Q--i 8053480 4169w 3b010000 1000 1000 rxrpc afs@54321: ka
> $
>
> After the patch, the invalidated key is removed when the code exits:
>
> $ cat /proc/keys | grep afs@54321
> $
>
> Fixes: f3441d4125fc ("rxrpc: Copy client call parameters into rxrpc_call earlier")
> Signed-off-by: Anderson Nascimento <anderson@allelesecurity.com>
> Co-developed-by: David Howells <dhowells@redhat.com>
> Signed-off-by: David Howells <dhowells@redhat.com>
> cc: Marc Dionne <marc.dionne@auristor.com>
> cc: Eric Dumazet <edumazet@google.com>
> cc: "David S. Miller" <davem@davemloft.net>
> cc: Jakub Kicinski <kuba@kernel.org>
> cc: Paolo Abeni <pabeni@redhat.com>
> cc: Simon Horman <horms@kernel.org>
> cc: linux-afs@lists.infradead.org
> cc: netdev@vger.kernel.org
> cc: stable@kernel.org
>
> diff --git a/net/rxrpc/call_object.c b/net/rxrpc/call_object.c
> index 918f41d97a2f..8d874ea428ff 100644
> --- a/net/rxrpc/call_object.c
> +++ b/net/rxrpc/call_object.c
> @@ -694,6 +694,7 @@ static void rxrpc_destroy_call(struct work_struct *work)
> rxrpc_put_bundle(call->bundle, rxrpc_bundle_put_call);
> rxrpc_put_peer(call->peer, rxrpc_peer_put_call);
> rxrpc_put_local(call->local, rxrpc_local_put_call);
> + key_put(call->key);
> call_rcu(&call->rcu, rxrpc_rcu_free_call);
> }
>
>
--
Anderson Nascimento
Allele Security Intelligence
https://www.allelesecurity.com
Anderson Nascimento <anderson@allelesecurity.com> wrote:
> @@ -227,6 +227,7 @@ static struct rxrpc_call *rxrpc_alloc_client_call(struct rxrpc_sock *rx,
>
> ret = rxrpc_init_client_call_security(call);
> if (ret < 0) {
> + key_put(call->key);
> rxrpc_prefail_call(call, RXRPC_CALL_LOCAL_ERROR, ret);
> rxrpc_put_call(call, rxrpc_call_put_discard_error);
> return ERR_PTR(ret);
It's probably better to do this in rxrpc_destroy_call() if we can as a last
fallback. In fact it's probably always leaking the call->key, not just under
this circumstance.
David
© 2016 - 2026 Red Hat, Inc.