CVE-2026-31425: Linux Kernel Privilege Escalation Flaw

CVE-2026-31425 Overview

A null pointer dereference vulnerability exists in the Linux kernel's Reliable Datagram Sockets (RDS) InfiniBand (IB) subsystem. The flaw occurs in the rds_ib_get_mr() function when it extracts the rds_ib_connection from conn->c_transport_data and passes it to rds_ib_reg_frmr() for FRWR (Fast Registration Work Request) memory registration. On a fresh outgoing connection, the ic structure is allocated in rds_ib_conn_alloc() with i_cm_id set to NULL because the connection worker has not yet established the RDMA connection. When sendmsg() with RDS_CMSG_RDMA_MAP is called before connection establishment, the kernel crashes due to a null pointer dereference when accessing ic->i_cm_id->qp.

Critical Impact

This vulnerability allows local users to crash the kernel by triggering a null pointer dereference through the RDS sendmsg path before an InfiniBand connection is fully established, resulting in a denial of service condition.

Affected Products

• Linux Kernel with RDS over InfiniBand support enabled
• Systems utilizing RDMA/InfiniBand networking with RDS protocol
• Kernel configurations with CONFIG_RDS_RDMA enabled

Discovery Timeline

• April 13, 2026 - CVE CVE-2026-31425 published to NVD
• April 13, 2026 - Last updated in NVD database

Technical Details for CVE-2026-31425

Vulnerability Analysis

The vulnerability is a null pointer dereference that occurs due to a race condition between connection establishment and memory registration operations. When a user calls sendmsg() with the RDS_CMSG_RDMA_MAP control message on a fresh outgoing RDS connection, the system attempts to register memory for RDMA operations before the underlying InfiniBand connection is fully established.

The existing guard in rds_ib_reg_frmr() only checks for !ic (added in commit 9e630bcb7701), but this check is insufficient because the ic (InfiniBand connection) structure is allocated early in rds_ib_conn_alloc() and is always non-NULL once the connection object exists. However, the i_cm_id field within this structure remains NULL until rds_ib_conn_path_connect() creates the RDMA CM ID through the connection worker.

Root Cause

The root cause is an incomplete validation in the rds_ib_get_mr() function. While the code checks whether the ic pointer is non-NULL, it fails to verify that the connection is actually ready for RDMA operations by checking i_cm_id and qp (queue pair) pointers. The sendmsg path processes control messages before connection establishment, creating a window where FRMR registration can be attempted with uninitialized connection state.

The call trace demonstrates the vulnerability path:

• rds_sendmsg() → rds_cmsg_rdma_map() → __rds_rdma_map() → rds_ib_get_mr() → rds_ib_reg_frmr() → rds_ib_map_frmr() → rds_ib_post_reg_frmr()

At the final function, dereferencing ic->i_cm_id->qp triggers the crash because i_cm_id is NULL.

Attack Vector

The attack is locally exploitable by a user with access to RDS sockets. An attacker can create an RDS socket, initiate an outgoing connection, and immediately call sendmsg() with RDS_CMSG_RDMA_MAP before the InfiniBand connection worker completes establishment. This timing-based attack triggers the null pointer dereference in kernel context, causing a system crash and denial of service.

The vulnerability requires:

1. Local access to the system
2. Ability to create RDS sockets (typically requires CAP_NET_RAW or appropriate permissions)
3. InfiniBand/RDMA hardware or drivers present on the system

Detection Methods for CVE-2026-31425

Indicators of Compromise

• Kernel panic or oops messages referencing rds_ib_post_reg_frmr in the call trace
• KASAN reports showing null pointer dereference in the address range 0x0000000000000010-0x0000000000000017
• System crashes occurring during RDS socket operations over InfiniBand
• Audit logs showing repeated RDS socket creation followed by immediate sendmsg calls

Detection Strategies

• Monitor kernel logs for panic messages containing rds_ib_post_reg_frmr, rds_ib_map_frmr, or rds_ib_reg_frmr in the stack trace
• Deploy KASAN (Kernel Address Sanitizer) in development environments to detect null pointer dereferences early
• Enable RDS module tracing to identify abnormal sendmsg patterns before connection establishment
• Configure system watchdogs to capture kernel crash dumps for forensic analysis

Monitoring Recommendations

• Implement alerting on kernel oops events related to the net/rds/ib_frmr.c code path
• Monitor for unusual RDS socket activity patterns, particularly rapid socket creation and immediate RDMA mapping attempts
• Enable audit logging for socket system calls on systems using RDS over InfiniBand
• Deploy crash reporting infrastructure to collect and analyze kernel panic events

How to Mitigate CVE-2026-31425

Immediate Actions Required

• Update the Linux kernel to a patched version that includes the fix for this vulnerability
• If kernel update is not immediately possible, consider disabling the RDS kernel module using modprobe -r rds_rdma rds if RDS functionality is not required
• Restrict access to RDS socket creation by limiting capabilities or using namespace isolation
• Monitor systems for crash events indicating potential exploitation attempts

Patch Information

The fix adds comprehensive validation in rds_ib_get_mr() to verify that ic, i_cm_id, and qp are all non-NULL before proceeding with FRMR registration. When the connection is not ready, the function returns -ENODEV, which the existing error handling in rds_cmsg_send() converts to -EAGAIN for userspace retry and triggers rds_conn_connect_if_down() to start the connection worker.

Multiple patch commits are available for various kernel branches:

• Kernel Git Commit 23e07c340
• Kernel Git Commit 450ec93c0
• Kernel Git Commit 47de5b73d
• Kernel Git Commit 6b0a8de67
• Kernel Git Commit a54ecccfae
• Kernel Git Commit a5bfd14c9a

Workarounds

• Unload the RDS RDMA kernel modules if RDS over InfiniBand functionality is not required: modprobe -r rds_rdma
• Use kernel module blacklisting by adding blacklist rds_rdma to /etc/modprobe.d/blacklist.conf
• Implement network namespaces to isolate critical applications from systems requiring RDS functionality
• Apply mandatory access control policies (SELinux/AppArmor) to restrict which processes can create RDS sockets

# Disable RDS RDMA modules temporarily
modprobe -r rds_rdma rds

# Permanently blacklist if not needed
echo "blacklist rds_rdma" >> /etc/modprobe.d/blacklist-rds.conf
echo "blacklist rds" >> /etc/modprobe.d/blacklist-rds.conf

# Verify modules are not loaded
lsmod | grep rds