CVE-2024-50294

What it actually does

Missing lock when aborting a queued rxrpc call allows rxrpc_disconnect_client_call to remove the call from local->new_client_calls without synchronization, enabling a race that can unlink unrelated calls from the list.

Why it matters to the business

Network calls in affected Linux systems may hang or disappear unexpectedly, leading to application instability, failed remote operations, and potential service disruptions; urgency is low given no KEV listing or ransomware use but kernel-wide exposure remains a concern for many deployments.

How an attack unfolds

An attacker or local process triggers an abort (such as via signal) on a call between queuing for connection and I/O thread processing; without the client_call_lock the removal can race against other list operations and corrupt the wait queue for additional calls.

How to fix it

Apply the upstream fix that acquires client_call_lock before removing a call from its wait_link list; for flashplugin-nonfree on Ubuntu 14.04 LTS upgrade to version 11.2.202.554ubuntu0.14.04.1 or later.

How to confirm the fix worked

Confirm the client_call_lock acquisition is present around the list removal in rxrpc_disconnect_client_call and test abort scenarios under concurrent load to ensure no calls vanish from the queue.

Typical attack path

1. Queue a client call for connection handling
2. Induce abort or signal on the call before I/O thread pickup
3. Perform concurrent list operations to trigger the race
4. Observe or leverage resulting call disappearance or hangs

How to detect it

Inspect kernel logs for rxrpc call aborts followed by unexpected list state changes or hung tasks; correlate with any observed signal-induced aborts on client connections.

What your security team should do

• Prioritize kernel updates on all systems exposing rxrpc or kAFS workloads
• Review and apply the exact fixed package versions provided for any listed distributions
• Monitor EPSS trend stability and re-evaluate if new exploitation reports appear