CVE-2026-43469

What it actually does

This is a Linux kernel availability flaw in the RPC-over-RDMA transport path used by SunRPC/NFS over RDMA. If rpcrdma_post_recvs() exits early, such as during memory allocation failure or other receive work-request setup failure, the xprtrdma receive counter is not decremented. As a result, rpcrdma_xprt_drain() can wait forever for a completion condition that will never occur, leaving kernel worker threads blocked in uninterruptible sleep and potentially causing NFS/RDMA transport teardown, reconnect, or autoclose operations to hang. The practical technical impact is denial of service for systems using the affected xprtrdma/rpcrdma kernel code path, especially under high memory pressure.

Why it matters to the business

Systems that rely on Linux NFS over RDMA or other SunRPC-over-RDMA workloads may experience hung kernel workers, stalled storage access, degraded application performance, or service outages. The risk is most relevant to storage, HPC, virtualization, and clustered environments using RDMA-backed file services. Although the CVSS score indicates high availability impact, the EPSS score is currently low, the issue is not listed in CISA KEV, and there is no reported public exploit maturity in the provided data, so remediation should be prioritized based on exposure to NFS/RDMA and operational criticality rather than broad internet-wide exploitation pressure.

How an attack unfolds

An attacker or fault condition must reach a system using the affected Linux RPC-over-RDMA transport path. The vulnerable condition occurs when the kernel attempts to post RDMA receive work requests and exits early, for example because memory allocation fails under pressure. If the receive-in-progress counter is not decremented, later disconnect or drain logic waits indefinitely for the counter to reach zero. A remote adversary with network reachability to an exposed RDMA/SunRPC service may attempt to increase connection churn, trigger transport close/reconnect behavior, and contribute to resource pressure until the receive-posting failure path is reached. Once triggered, affected kernel worker threads can remain blocked, causing RPC/RDMA transport operations and dependent NFS workloads to stall. There are no named threat actors, ransomware use, or known exploitation-in-the-wild indicators in the provided intelligence.

How to fix it

Apply a Linux kernel update from the relevant distribution or kernel vendor that includes the xprtrdma fix for correctly decrementing re_receiving on early exit paths in rpcrdma_post_recvs(). No exact fixed package versions were provided, so use vendor advisories, kernel changelogs, or distribution security errata to identify the first fixed kernel for each platform. Where immediate patching is not possible, reduce exposure by disabling or avoiding NFS over RDMA/RPC-over-RDMA, using NFS over TCP where feasible, restricting RDMA/RPC network access to trusted hosts, isolating storage fabrics, and addressing sustained memory pressure that can make the vulnerable path more likely to occur. Rebooting into the fixed kernel is required for remediation because the vulnerable code is in the kernel.

How to confirm the fix worked

Confirm that systems have booted into a vendor kernel containing the xprtrdma/rpcrdma fix, not merely that an updated package is installed. Validate whether exposure exists by checking for loaded or available RDMA RPC modules such as rpcrdma and sunrpc, active NFS-over-RDMA mounts, RDMA interfaces, and services listening on storage/RDMA networks. Review kernel logs after remediation for absence of hung task reports involving xprtiod, xprt_autoclose, rpcrdma_xprt_disconnect, xprt_rdma_close, or rpcrdma_xprt_drain. In controlled non-production testing, exercise NFS/RDMA connect, disconnect, and failover behavior under safe memory-pressure conditions and verify that transport teardown completes without blocked kernel workers.

Typical attack path

1. Identify a Linux host or storage client/server using SunRPC/NFS over RDMA with the affected kernel code path.
2. Establish network interaction with the exposed RDMA/RPC service or otherwise cause RDMA transport activity.
3. Create conditions that increase receive posting failures, such as high connection churn, disconnect/reconnect cycles, or resource pressure.
4. Trigger an early exit in rpcrdma_post_recvs() while the receive counter remains incorrectly incremented.
5. Cause rpcrdma_xprt_drain() or disconnect/autoclose handling to wait indefinitely for a completion that never occurs.
6. Induce service degradation or denial of service for workloads depending on the affected RPC-over-RDMA transport.

How to detect it

To determine whether the issue may already have been triggered, review kernel logs, system journals, console logs, crash dumps, and monitoring alerts for hung task reports involving RPC-over-RDMA or SunRPC worker threads. Focus on messages showing kworker threads blocked for long periods, especially workqueue xprtiod and function names such as rpcrdma_xprt_disconnect, xprt_rdma_close, xprt_autoclose, rpcrdma_xprt_drain, or rpcrdma_post_recvs. Correlate these events with NFS/RDMA outages, storage latency spikes, transport reconnects, RDMA link errors, and host memory pressure or allocation failure events. Because this flaw causes denial of service rather than code execution, expected evidence is kernel hangs, blocked tasks, storage stalls, and RDMA/RPC transport failures rather than malware artifacts. There are no public threat actor or ransomware indicators in the provided data.

• INFO: task kworker/
• blocked for more than 122 seconds
• Workqueue: xprtiod xprt_autoclose
• rpcrdma_xprt_disconnect
• xprt_rdma_close
• xprt_autoclose
• rpcrdma_xprt_drain
• rpcrdma_post_recvs
• wait_for_completion
• [rpcrdma]
• [sunrpc]
• task:kworker
• state:D
• /proc/sys/kernel/hung_task_timeout_secs
• re_receiving

What your security team should do

• Inventory Linux systems using NFS over RDMA, RPC-over-RDMA, or loaded rpcrdma/xprtrdma-related kernel modules, and prioritize those supporting critical storage or clustered workloads.
• Patch and reboot exposed systems using vendor-provided fixed kernels; confirm the running kernel version after reboot.
• If patching is delayed, temporarily disable NFS/RDMA where operationally feasible or move affected workloads to NFS over TCP.
• Restrict RDMA and RPC storage network access to trusted clients and storage peers only; block untrusted network paths to RDMA-capable services.
• Monitor kernel logs for hung task messages and stack traces involving rpcrdma, xprtiod, xprt_autoclose, or sunrpc.
• Investigate sustained memory pressure on affected systems because low-memory conditions can increase the likelihood of triggering the flaw.
• Treat this as an availability issue with targeted operational risk rather than a currently widespread exploitation campaign, given low EPSS, no KEV listing, and no reported exploit maturity in the provided data.