CVE-2026-46053

What it actually does

This Linux kernel flaw is a local memory-corruption vulnerability in the RDS/RDMA memory-region cleanup path. When __rds_rdma_map() successfully hands scatter-gather/page ownership to the transport and then fails while copying the generated cookie back to user space, the error path may attempt to unpin or free resources that are already owned by the memory-region teardown path. That duplicate cleanup can create a double-free or use-after-free condition in kernel memory. A local attacker with the ability to exercise the affected RDS/RDMA interface could potentially crash the kernel or, with reliable heap manipulation, escalate privileges and gain kernel-level code execution.

Why it matters to the business

Systems running affected Linux kernels may be exposed to local privilege escalation or denial-of-service if untrusted users, compromised service accounts, containers, or workloads can access the vulnerable RDS/RDMA functionality. The CVSS score is high, but current public exploitation signals are low: EPSS is 0.00129, the vulnerability is not listed in CISA KEV, is not known to be used in ransomware campaigns, and has no reported exploit maturity. Even so, kernel privilege-escalation issues are operationally important because exploitation can turn a limited foothold into full host compromise.

How an attack unfolds

An attacker first needs local code execution or an account on a system running an affected Linux kernel with the vulnerable RDS/RDMA code available. The attacker opens or interacts with the RDS/RDMA interface and invokes the memory-registration path in a way that causes get_mr() to succeed, transferring ownership of pages or scatter-gather entries to the transport. The attacker then deliberately supplies a user-space destination that makes the cookie copy-back fail after that ownership transfer. On vulnerable kernels, the failure branch performs duplicate cleanup before the normal memory-region reference teardown also runs, causing the same resources to be released twice or accessed after release. Depending on kernel configuration, allocator state, and exploit reliability, this can result in a kernel panic or be shaped into memory corruption that allows privilege escalation.

How to fix it

Apply a kernel update from the Linux distribution or appliance vendor that includes the upstream fix for the RDS/RDMA memory-region cleanup bug. No exact fixed package versions were provided in the input, so track vendor advisories for the affected kernel branches and upgrade to the first kernel release that explicitly includes the fix for this issue. Reboot into the updated kernel after installation; merely installing the package is not sufficient if the old kernel remains running. If RDS/RDMA is not required, reduce exposure by disabling or blacklisting the rds and rds_rdma modules, preventing automatic loading, and removing unused RDMA/RDS dependencies where practical. On multi-tenant or shared systems, further reduce risk by limiting local shell access, restricting untrusted workloads, and applying container hardening because the flaw requires local access.

How to confirm the fix worked

Confirm the running kernel, not just the installed kernel package, has been updated by checking uname -a and the distribution package metadata after reboot. Validate against the vendor advisory or changelog for the specific kernel build to confirm the RDS/RDMA cleanup fix is included. Check whether RDS/RDMA exposure remains by reviewing loaded modules with lsmod, module configuration under /etc/modprobe.d/, and kernel configuration for RDS/RDMA support where available. If RDS/RDMA is not needed, verify that modprobe rds and modprobe rds_rdma fail or are blocked by policy. For negative testing, confirm ordinary users cannot load the modules or exercise unnecessary RDS/RDMA functionality. Monitor for absence of new kernel oops, BUG, KASAN, double-free, or RDS-related crash messages after patching.

Typical attack path

1. Gain local execution on a Linux host through a shell, compromised service, malicious workload, or container escape prerequisite.
2. Determine whether the affected kernel exposes RDS/RDMA functionality, such as a loaded rds or rds_rdma module or enabled RDS socket support.
3. Create or interact with the RDS/RDMA interface to reach the __rds_rdma_map() memory-registration path.
4. Submit parameters that allow memory-region creation to succeed while arranging for the generated cookie copy-back to user space to fail.
5. Trigger the vulnerable error path, causing duplicate cleanup of pages or scatter-gather resources.
6. Use the resulting kernel memory corruption to crash the host or attempt privilege escalation to root/kernel privileges.

How to detect it

Investigate whether exploitation was already attempted by reviewing kernel logs and crash telemetry for RDS/RDMA-related memory corruption. Primary sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dumps, kdump/vmcore artifacts, audit logs, and EDR process telemetry for local binaries interacting with RDS sockets or loading RDS modules. Look for kernel oops or panic events near messages referencing RDS, RDMA, memory-region mapping, invalid frees, double frees, use-after-free, refcount problems, KASAN reports, or faults in __rds_rdma_map and related RDS functions. Also review module load history for unexpected rds or rds_rdma loading on systems that do not normally use RDS/RDMA. Because public exploit details are not mature, detection should focus on behavioral evidence of local probing, suspicious module loading, and kernel memory-corruption crashes rather than a single definitive network signature.

• __rds_rdma_map
• rds_rdma_map
• rds_rdma
• rds
• KASAN: double-free
• KASAN: use-after-free
• KASAN: invalid-free
• BUG: unable to handle kernel
• general protection fault
• kernel BUG
• Oops:
• refcount_t: underflow
• RIP: 0010:__rds_rdma_map
• RIP: 0010:rds_rdma
• modprobe rds
• modprobe rds_rdma
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• /proc/modules

What your security team should do

• Prioritize patching Linux systems where untrusted local users, CI jobs, containers, shared hosting workloads, or exposed application accounts can execute code.
• Reboot systems after applying the fixed kernel and verify the running kernel version is the remediated version.
• Disable or blacklist rds and rds_rdma modules on systems that do not require RDS/RDMA.
• Inventory hosts with RDS/RDMA loaded or available, especially systems with RDMA-capable hardware or database/HPC configurations that may use RDS.
• Review recent kernel logs for RDS-related crashes, double-free warnings, invalid frees, page faults, or KASAN reports that may indicate attempted exploitation or instability.
• Because the vulnerability is local and not currently in KEV, balance emergency response against exposure: internet-facing status is less relevant than whether untrusted code can run on the host.
• Harden local execution boundaries by minimizing interactive access, tightening container privileges, disabling unnecessary module loading, and enforcing least privilege for service accounts.