In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix missing locking causing hanging calls
If a call gets aborted (e.g. because kafs saw a signal) between it being
queued for connection and the I/O thread picking up the call, the abort
will be prioritised over the connection and it will be removed from
local->new_client_calls by rxrpc_disconnect_client_call() without a lock
being held. This may cause other calls on the list to disappear if a race
occurs.
Fix this by taking the client_call_lock when removing a call from whatever
list its ->wait_link happens to be on.
Security readout for executives and security teams
Plain-English summary
A Linux kernel race in RxRPC can corrupt an internal call queue when a call is aborted at a precise time. Other queued calls may disappear and hang. This can disrupt systems using RxRPC or kAFS; the supplied CVSS score is 7.8, although the description does not establish data theft or active exploitation.
Executive priority
Schedule prompt remediation for exposed production systems, especially those dependent on AFS. The high score warrants attention, but the absence of documented active exploitation makes this a prioritized maintenance issue rather than an evidence-based emergency.
Technical view
An aborted RxRPC client call can be removed from local->new_client_calls without client_call_lock while awaiting I/O-thread processing. Concurrent list activity may then lose other calls, causing hangs. The stable fixes acquire client_call_lock before removing the call from the list referenced by wait_link.
Likely exposure
Exposure is limited to Linux kernels containing the flaw and workloads exercising RxRPC, including the described kAFS abort path. The supplied affected-version data names 6.2, 6.6.61, 6.11.8, and 6.12, but does not provide reliable downstream distribution ranges. The CVSS vector describes a local, low-privileged attack surface.
Exploitation context
The bundle marks this CVE as absent from KEV and provides no evidence of active exploitation or a public exploit. Triggering depends on a timing-sensitive race during call abortion and connection queuing. Treat exploitability as unconfirmed rather than impossible.
Researcher notes
The source establishes a CWE-667 locking failure and availability symptoms through list corruption. Although the supplied CVSS vector assigns high confidentiality, integrity, and availability impacts, the narrative directly demonstrates disappearing calls and hangs only. Affected-range precision and downstream backport coverage require vendor confirmation.
Mitigation direction
Update to a vendor-supported kernel containing the applicable stable fix.
Check distribution advisories for backport status; kernel version numbers alone may be misleading.
Prioritize systems actively using RxRPC or kAFS services.
If patching is delayed, obtain vendor-supported mitigations and monitor for unexplained call hangs.
Validation and detection
Inventory running kernel builds and identify systems using RxRPC or kAFS.
Map each kernel package to its distribution advisory and backported patch record.
Confirm the applicable stable fix commit is present in kernel source or package metadata.
After updating, reboot into the corrected kernel and verify the running build.
Review operational telemetry for recurring RxRPC or AFS call hangs.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-667: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-667 · source CWE mapping
Improper Locking
Improper Locking represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.