CVE-2026-52939: Linux Kernel RDS/IB NULL Pointer Crash – Denial of Service

Technical summary

The vulnerability exists in a code path mismatch within the RDS/IB layer. The transmit function rds_ib_xmit_atomic() unconditionally programs masked atomic opcodes (IB_WR_MASKED_ATOMIC_CMP_AND_SWP or IB_WR_MASKED_ATOMIC_FETCH_AND_ADD) for RDS atomic control messages. However, the completion handler rds_ib_send_unmap_op() only contains case statements for non-masked atomic opcodes. When a masked atomic completion arrives, the opcode check falls through to default, returning NULL for the rds_message (rm) pointer while leaving send->s_op set. The subsequent call to rds_ib_send_cqe_handler() then dereferences the NULL rm pointer at offset 0x190 (rm->m_final_op), triggering a general protection fault in softirq context. The fix involves adding case statements for the masked opcodes alongside the existing non-masked ones, as both types map to the same rds_message.atomic union member.

Business impact

An unprivileged local user can remotely crash a Linux system running RDS/IB by sending a crafted atomic message over an existing RDS connection. This represents a local denial-of-service vector with no authentication required beyond socket-level access to RDS. For environments using Mellanox InfiniBand adapters with RDS enabled, kernel panic recovery time may be significant, and repeated exploitation could disrupt service availability. Workloads relying on RDS for cluster communication, HPC, or storage protocols are most at risk.

Affected systems

The vulnerability affects all versions of the Linux kernel with RDS/IB support. Exploitation requires an active RDS/IB connection and hardware that natively supports masked atomic operations—primarily Mellanox MLX4 and MLX5 adapters. Systems using other InfiniBand vendors or non-RDS networking stacks are not affected. The vulnerability is in the mainline kernel and backported stable branches that include the vulnerable RDS/IB code.

Exploitability

Exploitability is straightforward and requires no privileged access or complex setup. Any unprivileged user with local socket access and an active RDS/IB connection can trigger the crash by sending a single atomic control message via AF_RDS sendmsg(). The CVSS score of 5.5 reflects the local attack vector and high availability impact; the low complexity and lack of user interaction mean exploitation is trivial once conditions are met. No CISA KEV listing is present, suggesting limited evidence of active exploitation in the wild, though the trivial trigger makes it a practical DoS vector.

Remediation

Apply a kernel update that includes the fix for rds_ib_send_unmap_op(). The remediation adds case statements to handle IB_WR_MASKED_ATOMIC_CMP_AND_SWP and IB_WR_MASKED_ATOMIC_FETCH_AND_ADD opcodes in the completion handler. Verify the patch is present in your kernel version by checking the net/rds/ib_send.c file around the send-unmap function. If RDS is not required on affected systems, disabling RDS modules via modprobe blacklist or kernel configuration is an immediate mitigation.

Patch guidance

Identify your Linux kernel version and check your vendor's security advisory or kernel.org for the patched version. Patch releases should be available for currently supported stable branches (LTS and regular releases). If you maintain custom kernels, backport the fix from the upstream commit that resolves the masked atomic opcode handling. Test the patched kernel in a non-production environment first, particularly if you use RDS/IB for cluster communication, to verify compatibility with your InfiniBand drivers and userspace RDS libraries.

Detection guidance

Monitor kernel logs for the error message 'rds_ib_send_unmap_op: unexpected opcode 0xd in WR!' or general protection faults with a stack trace mentioning rds_ib_send_cqe_handler(). Kernel panic dumps and kdump logs should show the crash at net/rds/ib_send.c:282. Network detection is difficult without RDS protocol awareness, but correlation of RDS/IB connection establishment with subsequent kernel crashes on systems with MLX4/MLX5 adapters is a strong indicator. Enable kernel KASAN (Kernel Address Sanitizer) in development/test environments to catch null-ptr-deref conditions early.

Why prioritize this

Although CVSS 5.5 is moderate, this vulnerability should be treated as HIGH priority for systems with active RDS/IB deployments. The trivial exploit trigger (single unprivileged sendmsg call), kernel panic impact, and potential service disruption warrant rapid patching. Organizations using HPC clusters, storage appliances, or distributed databases over InfiniBand should prioritize immediately. For systems without RDS/IB enabled or usage, risk is low, but kernel security updates should still be applied systematically.

Risk score, explained

The CVSS 3.1 score of 5.5 (MEDIUM) reflects a local attack vector (AV:L), low complexity (AC:L), low privilege requirement (PR:L), no user interaction (UI:N), and high availability impact (A:H). The score appropriately captures the availability risk but may underweight the operational impact of kernel panics in production environments. For mission-critical RDS/IB infrastructure, consider this vulnerability more severely in your risk framework.

Frequently asked questions