CVE-2022-48773

What it actually does

Improper error handling in rpcrdma_ep_create leaves non-NULL pointers containing error values; subsequent calls to rpcrdma_ep_destroy attempt to free them, triggering invalid pointer dereference and kernel oops.

Why it matters to the business

Systems using NFS over RDMA may experience sudden kernel crashes and service restarts, causing temporary loss of network file access and requiring manual intervention to restore availability.

How an attack unfolds

An attacker triggers failure paths inside rpcrdma_ep_create (for example by exhausting resources or supplying malformed RDMA parameters) so that the resulting error state is not cleared; later destruction of the endpoint then dereferences the stale pointers and crashes the kernel.

How to fix it

Upgrade the Linux kernel to a fixed version listed for the distribution in use (for example Debian 11 to 5.10.92-1, Debian 12/13 to 5.15.15-1, or Ubuntu 20.04 LTS variants to the corresponding 5.4.0- or 5.15.0- packages provided by the vendor). Reboot after installation.

How to confirm the fix worked

Verify the running kernel version matches or exceeds the fixed release for the distribution; confirm absence of the vulnerable rpcrdma_ep_create error-handling pattern by inspecting kernel source or changelog entries referencing this fix.

Typical attack path

1. Establish an RDMA-capable NFS mount or connection that exercises the xprtrdma transport
2. Force an error condition during endpoint creation (resource exhaustion, invalid parameters)
3. Allow the transport teardown path to execute rpcrdma_ep_destroy on the uncleaned pointers
4. Observe or induce kernel oops and potential system instability

How to detect it

Search kernel logs (dmesg, /var/log/kern.log, journalctl) for oops or panic entries that reference rpcrdma_ep_create or rpcrdma_ep_destroy; look for stack traces involving pointer dereference during RDMA endpoint teardown.

• rpcrdma_ep_create
• rpcrdma_ep_destroy
• xprtrdma

What your security team should do

• Prioritize patching on any hosts that expose NFS/RDMA or run workloads dependent on the xprtrdma module
• Monitor kernel logs for oops messages containing rpcrdma after applying updates to confirm resolution
• Apply vendor kernel updates within normal change windows given the low EPSS and absence from KEV