Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-52939

CVE-2026-52939: Linux Kernel Use-After-Free Vulnerability

CVE-2026-52939 is a use-after-free vulnerability in the Linux kernel's RDS/IB implementation that causes NULL pointer dereference. This post explains its technical details, affected versions, impact, and mitigation.

Published:

CVE-2026-52939 Overview

CVE-2026-52939 is a NULL pointer dereference vulnerability in the Linux kernel's Reliable Datagram Sockets (RDS) over InfiniBand (IB) implementation. The flaw resides in rds_ib_send_cqe_handler() and is triggered by masked atomic completions. The function rds_ib_xmit_atomic() always programs a masked atomic opcode (IB_WR_MASKED_ATOMIC_CMP_AND_SWP or IB_WR_MASKED_ATOMIC_FETCH_AND_ADD) for every RDS atomic cmsg, but the completion-side switch in rds_ib_send_unmap_op() does not handle these opcodes. The result is a NULL rm pointer dereference in softirq context, leading to a kernel panic.

Critical Impact

An unprivileged local user can crash the kernel by sending an AF_RDSsendmsg() with an atomic cmsg over an active RDS/IB connection on hardware that natively supports masked atomics (mlx4, mlx5).

Affected Products

  • Linux kernel — net/rds subsystem with RDS over InfiniBand support
  • Systems using Mellanox mlx4 InfiniBand adapters
  • Systems using Mellanox mlx5 InfiniBand adapters

Discovery Timeline

  • 2026-06-24 - CVE-2026-52939 published to NVD
  • 2026-06-24 - Last updated in NVD database

Technical Details for CVE-2026-52939

Vulnerability Analysis

The vulnerability is a NULL pointer dereference [CWE-476] in the Linux kernel RDS/IB send completion path. When userspace submits an RDS atomic control message, rds_ib_xmit_atomic() unconditionally programs a masked atomic work request, using opcode IB_WR_MASKED_ATOMIC_CMP_AND_SWP or IB_WR_MASKED_ATOMIC_FETCH_AND_ADD. On completion, rds_ib_send_unmap_op() runs a switch over the opcode but only matches the non-masked variants. The masked opcodes fall through to the default branch, which returns rm == NULL while leaving send->s_op set.

Next, rds_ib_send_cqe_handler() dereferences rm->m_final_op, triggering a general protection fault in softirq context. The reported KASAN trace shows a null-ptr-deref in the range 0x0000000000000190-0x0000000000000197 at rds_ib_send_cqe_handler+0x25c/0xb10 in net/rds/ib_send.c:282, followed by Kernel panic - not syncing: Fatal exception in interrupt.

Root Cause

The root cause is incomplete opcode handling in rds_ib_send_unmap_op(). The transmit path generates masked atomic work requests, but the completion path's switch statement only covers IB_WR_ATOMIC_CMP_AND_SWP and IB_WR_ATOMIC_FETCH_AND_ADD. The fix routes the masked opcodes to the same case as the non-masked ones because they map to the same struct rds_message.atomic union member, making the existing container_of() and rds_ib_send_unmap_atomic() logic correct for both.

Attack Vector

A local, unprivileged attacker with the ability to open an AF_RDS socket and reach an active RDS/IB connection can trigger the panic. No special capabilities are required. The attacker calls sendmsg() with an atomic cmsg on hardware that natively accepts masked atomics, such as Mellanox mlx4 or mlx5 adapters. The resulting NULL dereference executes in interrupt context, producing a denial-of-service via kernel panic.

No verified public exploit code is available. Refer to the upstream commits, including Kernel Git Commit 4fd34669 and Kernel Git Commit a0148342, for the patch details.

Detection Methods for CVE-2026-52939

Indicators of Compromise

  • Kernel log message: RDS/IB: rds_ib_send_unmap_op: unexpected opcode 0xd in WR! immediately preceding a panic.
  • Kernel oops with KASAN: null-ptr-deref at rds_ib_send_cqe_handler+0x25c/0xb10 in net/rds/ib_send.c.
  • Call trace including poll_scq, rds_ib_tasklet_fn_send, and tasklet_action_common in softirq context.
  • Unexpected Kernel panic - not syncing: Fatal exception in interrupt events on hosts with mlx4 or mlx5 adapters.

Detection Strategies

  • Monitor dmesg and /var/log/kern.log for the unexpected opcode 0xd in WR string, which is the canonical signal of this bug.
  • Track unexpected reboots or crash dumps on RDS/IB enabled hosts, correlating with AF_RDS socket usage.
  • Audit which processes load the rds and rds_rdma kernel modules; unexpected loaders on production hosts warrant investigation.

Monitoring Recommendations

  • Forward kernel logs from RDMA-capable hosts to a centralized logging or SIEM platform for pattern matching on RDS oops signatures.
  • Enable kdump to capture vmcore files for post-mortem analysis when panics occur.
  • Alert on modprobe or insmod events targeting rds or rds_rdma modules on systems that should not require them.

How to Mitigate CVE-2026-52939

Immediate Actions Required

  • Apply the upstream Linux kernel patches that extend the rds_ib_send_unmap_op()switch to cover IB_WR_MASKED_ATOMIC_CMP_AND_SWP and IB_WR_MASKED_ATOMIC_FETCH_AND_ADD.
  • Inventory hosts running RDS over InfiniBand with mlx4 or mlx5 adapters and prioritize those for patching.
  • If patching is not immediately possible, blacklist or unload the rds_rdma module on systems that do not require RDS/IB.
  • Restrict AF_RDS socket creation to trusted users by limiting local access on affected hosts.

Patch Information

The fix is committed upstream across multiple stable branches. Relevant commits include Kernel Git Commit 0f22412a, Kernel Git Commit 0f7baa82, Kernel Git Commit 34080db3, Kernel Git Commit 4dd262f8, Kernel Git Commit 4fd34669, Kernel Git Commit 6e461516, Kernel Git Commit a0148342, and Kernel Git Commit dcf45812. Consume the patched kernel from your Linux distribution vendor once available.

Workarounds

  • Prevent the rds and rds_rdma modules from loading via /etc/modprobe.d/ blacklist entries on hosts that do not need RDS/IB.
  • Remove or restrict access to the CAP_NET_RAW-independent AF_RDS socket family using seccomp profiles or LSM policies where feasible.
  • Disable InfiniBand interfaces on hosts that do not require RDMA traffic until the patched kernel is installed.
bash
# Blacklist the RDS modules to mitigate exposure until patching
echo 'blacklist rds'      | sudo tee /etc/modprobe.d/blacklist-rds.conf
echo 'blacklist rds_rdma' | sudo tee -a /etc/modprobe.d/blacklist-rds.conf
echo 'install rds /bin/true'      | sudo tee -a /etc/modprobe.d/blacklist-rds.conf
echo 'install rds_rdma /bin/true' | sudo tee -a /etc/modprobe.d/blacklist-rds.conf

# Verify the modules are not currently loaded
lsmod | grep -E 'rds|rds_rdma'

# If loaded, unload them (will fail if in use)
sudo modprobe -r rds_rdma rds

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.