CVE-2026-53355

What it actually does

This vulnerability is a use-after-free condition in the Linux kernel Reliable Datagram Sockets over InfiniBand (RDS/IB) code. During failed queue pair setup, the error-unwind path can free the i_sends send-ring allocation but leave the pointer populated. If connection teardown or a later shutdown path runs again, the kernel may treat that stale pointer as still-owned memory and operate on memory that has already been freed. The most likely technical outcomes are kernel memory corruption, kernel panic, denial of service, or potentially privilege-relevant memory corruption if an attacker can reliably trigger and shape the failing RDS/IB setup path. Exploit maturity is currently reported as none, EPSS is low, and this issue is not listed in CISA KEV.

Why it matters to the business

Systems that use Linux kernel RDS over InfiniBand could be exposed to crashes or instability if the vulnerable setup and teardown sequence is triggered. In environments using InfiniBand-backed database clusters, high-performance computing, or low-latency interconnects, this can affect availability of workloads that rely on kernel networking stability. Because there is no known public exploit activity, no KEV listing, and a low EPSS score, the immediate widespread exploitation risk appears low; however, kernel memory-safety flaws should still be prioritized on systems where RDS/IB is enabled or where untrusted local users can interact with RDS sockets.

How an attack unfolds

An attacker would need access to a system configuration where the Linux RDS/IB code path is present and usable, typically requiring the RDS kernel module and InfiniBand-related networking support. The attacker would attempt to initiate or manipulate an RDS/IB connection setup in a way that causes rds_ib_setup_qp() to fail after the send ring is allocated but before receive resources are fully allocated. That failure enters the error-unwind path, which frees the send-ring memory without clearing the pointer. A subsequent shutdown or repeated teardown path may then interpret the stale pointer as valid and access or free the already-released allocation. Depending on memory layout, timing, allocator behavior, and kernel hardening, this may produce a kernel crash or potentially more complex memory corruption. No named threat actors or active exploitation campaigns are currently associated with this vulnerability.

How to fix it

Apply a Linux kernel update that includes the fix for the RDS/IB teardown error-unwind path, specifically the change that clears i_sends after vfree() when rds_ib_setup_qp() fails. If exact vendor package versions are not available, use the latest kernel updates from the relevant Linux distribution or kernel vendor and confirm the advisory for this CVE is included. As mitigation where patching is delayed, disable or avoid loading RDS/RDS-IB functionality on systems that do not require it, restrict access to RDS sockets where possible, and limit local shell or workload access for untrusted users. Systems that rely on InfiniBand and RDS for production workloads should test kernel updates in staging before rollout because kernel and driver updates can affect high-performance networking behavior.

How to confirm the fix worked

Confirm that the running kernel version includes the vendor fix for this vulnerability, not only that an updated package is installed. Reboot into the patched kernel where required. Check whether RDS-related modules are loaded using module inventory commands and verify whether RDS/IB is actually required. Review vendor changelogs or kernel source patches for the corrective behavior: the rds_ib_setup_qp() error path should clear the i_sends pointer after freeing it. For exposure validation, identify systems with RDS, rds_rdma, rds_tcp, or rds_ib modules present or loaded, InfiniBand drivers active, and workloads that create AF_RDS sockets. For regression validation, monitor kernel logs after upgrade for RDS/IB warnings, kernel oops messages, KASAN reports, or unexpected network-driver instability.

Typical attack path

1. Identify a Linux system with RDS/IB kernel functionality available or loadable.
2. Confirm that the environment supports RDS over InfiniBand or exposes code paths that can reach RDS/IB queue-pair setup.
3. Trigger RDS/IB connection setup while influencing conditions that cause setup failure after i_sends allocation and before i_recvs allocation.
4. Allow or force connection teardown, retry, or shutdown handling to run after the partial setup failure.
5. Cause the stale i_sends pointer to be treated as a live allocation during the later shutdown path.
6. Leverage the resulting use-after-free condition to crash the kernel or attempt further memory-corruption exploitation.

How to detect it

There are no public, reliable exploitation-specific indicators for this vulnerability at this time. Detection should focus on signs that the vulnerable RDS/IB path was exercised and resulted in memory corruption or kernel instability. Review kernel logs, persistent journal entries, crash dumps, hypervisor console logs, and monitoring alerts for RDS, InfiniBand, queue-pair setup failure, use-after-free, KASAN, double-free, general protection fault, kernel oops, or panic messages. Pay particular attention to crashes involving rds_ib_setup_qp(), RDS connection shutdown, send-ring cleanup, vfree(), or InfiniBand queue-pair setup/teardown. If kernel crash dumps are available, inspect stack traces for RDS/IB functions and determine whether failure occurred during partial connection startup followed by teardown. Also review module load history for rds, rds_rdma, rds_tcp, rds_ib, ib_core, and related InfiniBand drivers to determine whether the vulnerable code path was reachable.

• rds_ib_setup_qp
• rds_ib_conn_shutdown
• rds_ib_conn_path_shutdown
• rds_ib_destroy_qp
• rds_ib_send
• rds_ib_recv
• RDS/IB
• rds_ib
• rds_rdma
• AF_RDS
• use-after-free
• KASAN: use-after-free
• BUG: KASAN
• kernel BUG
• kernel NULL pointer dereference
• general protection fault
• kernel panic
• Oops:
• vfree
• i_sends
• i_recvs
• ib_create_qp
• ib_destroy_qp

What your security team should do

• Prioritize patching Linux systems where RDS over InfiniBand is enabled, used by clustered applications, or available to untrusted local users.
• Inventory hosts with RDS/RDS-IB modules present or loaded and distinguish actively used systems from those where the feature can be disabled.
• Apply vendor kernel updates and reboot into the fixed kernel; verify the running kernel, not just installed packages.
• Where RDS/IB is not required, disable the relevant modules or prevent them from loading as a compensating control.
• Increase monitoring for kernel oops, panic, KASAN, slab, or RDS-related errors on exposed systems until patched.
• Treat unexplained crashes on RDS/IB-capable hosts as potentially security-relevant and preserve kernel logs, crash dumps, and module state for analysis.
• Because this is not KEV-listed, not ransomware-associated, and has low EPSS, schedule broadly according to normal kernel-risk processes, but accelerate remediation for InfiniBand/RDS production clusters.