In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix key reference...

Description

In the Linux kernel, the following vulnerability has been resolved:

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
$

Basic information

Type
unreviewed
Severity
medium
Advisory on GitHub
Open advisory ↗
Repository advisory
Source code
Not specified
Published (advisory)
2026-04-24 15:32:36 UTC
Updated
2026-04-27 21:31:55 UTC
NVD published
2026-04-24

EPSS Score

Score Percentile
0.01% 1.69%

CVSS Scores

Base score Version Severity Vector
5.5 3.1
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H Click to expand
Attack vector (AV:L)
They already need access on the box, or another person has to do something wrong; it’s not a remote drive-by.
Attack complexity (AC:L)
Once they can reach the bug, pulling it off is straightforward—no weird race conditions or rare setup.
Privileges required (PR:L)
A normal user session is enough; they don’t have to be admin.
User interaction (UI:N)
Nobody has to click “OK” or open a trap file; it can work without a victim helping.
Scope (S:U)
Damage stays in the same “trust bubble” as the broken component—no big spill into unrelated systems.
Confidentiality (C:N)
Doesn’t really leak secrets in a meaningful way.
Integrity (I:N)
Data isn’t meaningfully altered or forged.
Availability (A:H)
Could take the service down hard or make it unusable for people who depend on it.

Identifiers

References

cvelogic Threat Intelligence