CVE-2026-52939

What it actually does

This flaw is a Linux kernel denial-of-service issue in the RDS over InfiniBand implementation. When an unprivileged process sends an RDS atomic control message over an active RDS/IB connection, the transmit path may program a masked atomic work request, but the completion handler fails to recognize the masked atomic opcode. That leaves the expected RDS message pointer unset, and the send completion handler dereferences a NULL pointer in softirq/interrupt context. The result is a kernel oops and, depending on panic settings and system configuration, a full system crash or reboot.

Why it matters to the business

Successful exploitation can crash Linux systems that have RDS over InfiniBand enabled and reachable, causing application outages, failed jobs, interrupted database or clustered workloads, and possible service failover events. The risk is highest in environments using RDMA/InfiniBand hardware such as mlx4 or mlx5 with active RDS/IB connections. The vulnerability is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, but the local/unprivileged trigger and kernel-crash outcome make it important for exposed high-availability or compute infrastructure.

How an attack unfolds

An attacker first needs code execution as an unprivileged local user, container workload, or otherwise able process on a Linux host where AF_RDS and RDS over InfiniBand are available and an RDS/IB connection can be established. The attacker opens an AF_RDS socket and sends an RDS atomic control message using sendmsg(). The RDS/IB transmit path creates a masked atomic InfiniBand work request, such as masked compare-and-swap or masked fetch-and-add. On supported hardware, including mlx4 and mlx5, the hardware accepts the request and later returns a completion. During completion handling, the vulnerable kernel code does not handle the masked atomic opcode correctly, returns a NULL message pointer, and then dereferences it in rds_ib_send_cqe_handler(). Because this occurs in softirq context, the fault can produce a kernel oops and may panic the host, resulting in denial of service.

How to fix it

Upgrade to a Linux kernel version that includes the fix for handling masked atomic opcodes in the RDS/IB send completion path. If vendor fixed-version information is not yet available, track the relevant distribution kernel advisories and apply the first security or stable kernel update that references this RDS/IB NULL dereference fix. As interim mitigation, disable or unload unused RDS/RDMA/InfiniBand functionality where operationally feasible, restrict loading of the rds and rds_rdma/rds_tcp-related modules, limit local shell or workload execution on systems with RDS/IB enabled, and ensure only trusted workloads can access AF_RDS sockets. On systems that do not require RDS, remove or blacklist the RDS kernel modules and reboot or otherwise ensure the vulnerable code is no longer loaded.

How to confirm the fix worked

Confirm the system is running a vendor kernel that contains the patch for masked atomic opcode handling in net/rds/ib_send.c. Validate through vendor package metadata, kernel changelogs, or source inspection that masked atomic opcodes are handled alongside the non-masked atomic opcodes in rds_ib_send_unmap_op(). Check whether RDS modules are loaded with tools such as lsmod, modinfo, or /proc/modules, and verify whether AF_RDS sockets are present via socket inventory tooling. For mitigation validation, confirm that RDS modules cannot be loaded after reboot if they are not required, that RDMA/RDS services are disabled where applicable, and that no active RDS/IB connections exist on hosts that should not use them. In test environments only, a controlled reproduction using an RDS atomic sendmsg() over RDS/IB should no longer produce the kernel warning, NULL dereference, or panic after patching.

Typical attack path

1. Gain the ability to run an unprivileged process on a vulnerable Linux host.
2. Confirm that RDS/IB support is present, AF_RDS sockets are usable, and an active RDS over InfiniBand path can be established.
3. Create an AF_RDS socket and prepare an RDS atomic control message.
4. Use sendmsg() to transmit the atomic control message over the active RDS/IB connection.
5. Cause the kernel to submit a masked atomic InfiniBand work request.
6. Wait for the send completion path to process the masked atomic opcode.
7. Trigger the NULL pointer dereference in rds_ib_send_cqe_handler(), causing a kernel oops, panic, reboot, or service outage.

How to detect it

Detection is primarily host-based because exploitation results in kernel faults rather than distinctive network payloads. Review kernel logs, journald, syslog, dmesg output, crash dumps, kdump/vmcore records, and infrastructure monitoring for unexpected reboots or panics on systems with RDS/IB enabled. Look for messages referencing rds_ib_send_unmap_op(), unexpected opcode 0xd, rds_ib_send_cqe_handler(), NULL pointer dereference, general protection fault, or kernel panic in interrupt/softirq context. Correlate crash times with local user activity, container starts, batch jobs, RDMA/RDS connection activity, and unusual AF_RDS socket usage. Where auditd or eBPF telemetry is available, investigate processes creating AF_RDS sockets or invoking sendmsg() against RDS sockets shortly before a crash. Because the symptom is a denial-of-service crash, absence of logs after the event may be normal; use persistent journald, remote syslog, netconsole, pstore, kdump, and out-of-band management logs to preserve evidence.

• RDS/IB: rds_ib_send_unmap_op: unexpected opcode 0xd in WR!
• rds_ib_send_cqe_handler
• KASAN: null-ptr-deref
• Kernel panic - not syncing: Fatal exception in interrupt
• general protection fault [#1] SMP KASAN
• net/rds/ib_send.c:282
• poll_scq (net/rds/ib_cm.c:274)
• rds_ib_tasklet_fn_send
• tasklet_action_common
• handle_softirqs
• run_ksoftirqd
• IB_WR_MASKED_ATOMIC_CMP_AND_SWP
• IB_WR_MASKED_ATOMIC_FETCH_AND_ADD
• AF_RDS
• sendmsg

What your security team should do

• Prioritize patching Linux hosts that use InfiniBand/RDMA, mlx4/mlx5 adapters, clustered storage, HPC, database clustering, or other workloads that rely on RDS over InfiniBand.
• Inventory systems with RDS-related kernel modules loaded or available, including rds, rds_rdma, and InfiniBand/RDMA modules.
• If RDS is not required, disable or blacklist the RDS modules and verify the setting persists after reboot.
• Restrict untrusted local user access and untrusted container workloads on hosts where RDS/IB must remain enabled until patched.
• Monitor kernel logs, crash dumps, and host reboot events for RDS/IB send completion errors and NULL pointer dereferences.
• Ensure kernel panic and kdump/crash dump policies preserve forensic evidence for unexpected crashes.
• Track Linux distribution advisories for exact fixed kernel package versions and deploy updates through normal kernel patch management.
• Treat unexplained kernel panics on RDS/IB hosts as potentially security-relevant even though public exploitation and KEV listing are not currently reported.