CVE-2026-43502

What it actually does

This is a Linux kernel vulnerability in the RDS networking subsystem’s zerocopy send cleanup path. A local, low-privileged user who can exercise RDS send operations may trigger an error condition after user pages have been pinned but before the message is queued to the socket. The vulnerable cleanup logic can misclassify zerocopy-backed message state and release or account for memory incorrectly. Depending on kernel configuration, runtime conditions, and allocator state, this type of bug may lead to kernel memory corruption, use-after-free-style behavior, kernel crash, information disclosure, or local privilege escalation. The CVSS vector is local attack, low complexity, low privileges required, no user interaction, with potential high confidentiality, integrity, and availability impact.

Why it matters to the business

Successful exploitation could allow a local user or compromised low-privileged process on a Linux host to crash the system or potentially gain elevated kernel-level privileges. This is most concerning for multi-user Linux systems, shared compute platforms, container hosts where kernel attack surface is reachable from workloads, and systems with RDS kernel support enabled or loadable. It is not listed in CISA KEV, has no known ransomware association, and currently has very low EPSS, so broad internet-scale exploitation is not indicated; however, kernel local privilege escalation flaws can become high priority if public exploit code appears.

How an attack unfolds

An attacker first needs local code execution with low privileges on a vulnerable Linux system. They then attempt to access the RDS socket functionality and perform zerocopy send operations crafted to fail after user pages have been pinned but before the RDS message is attached to the socket send queue. In the vulnerable code path, cleanup relies on message queue state rather than the zerocopy notifier state, causing the kernel to handle pinned pages and payload ownership incorrectly. By repeatedly shaping this failure path, an attacker may be able to induce kernel memory corruption or a crash; with further exploit development, the same primitive may be used to manipulate kernel memory and elevate privileges. Exploitation reliability depends heavily on kernel version, RDS availability, module loading policy, hardening options, and memory layout.

How to fix it

Upgrade to a Linux kernel version that contains the upstream fix for the RDS zerocopy send cleanup path. Because no exact fixed package versions were provided, obtain patched kernels from the relevant Linux distribution or kernel vendor advisory for CVE-2026-43502 and confirm that the patch changes RDS message purge behavior to use the zerocopy notifier as the cleanup discriminator. If immediate patching is not possible, reduce exposure by disabling or preventing use of the RDS kernel modules where operationally feasible, restricting module auto-loading, limiting untrusted local shell access, and strengthening container isolation so workloads cannot reach unnecessary kernel networking features. Reboot into the patched kernel after installation; merely installing the package is not sufficient if the running kernel remains vulnerable.

How to confirm the fix worked

Confirm the running kernel version, not only the installed package version, after remediation. Validate with vendor advisories or changelogs that the deployed kernel includes the RDS zerocopy cleanup fix. Check whether RDS support is present or loaded using standard module and kernel configuration checks such as lsmod, modinfo, /proc/modules, and distribution kernel config files. Confirm that systems have been rebooted into the fixed kernel. If mitigation rather than patching is used, verify that rds, rds_tcp, and rds_rdma modules cannot be loaded by unprivileged activity and that no applications require RDS functionality. For exposure testing, avoid running untrusted proof-of-concept code on production systems; use a controlled lab kernel and confirm that crafted zerocopy RDS send failure cases no longer produce kernel warnings, oopses, page accounting errors, or crashes.

Typical attack path

1. Gain local execution as a low-privileged user or through a compromised application account.
2. Check whether RDS socket support is available, built into the kernel, or loadable as a module.
3. Create RDS socket activity using zerocopy send behavior.
4. Force an early send failure after page pinning but before the RDS message is queued.
5. Trigger the vulnerable cleanup path in the kernel RDS message purge logic.
6. Repeat or shape the condition to cause a kernel crash, memory corruption, or privilege escalation.
7. If privilege escalation succeeds, execute follow-on actions as root or with kernel-level control.

How to detect it

Review kernel and system logs for evidence of crashes or warnings in the RDS subsystem, especially around zerocopy send, page pinning, message purge, or socket cleanup. Relevant sources include journalctl -k, /var/log/kern.log, /var/log/messages, dmesg output, crash dumps, kdump/vmcore analysis, audit logs for unusual local execution, and EDR telemetry showing attempts to load or use RDS modules. Look for kernel oops, BUG, WARNING, KASAN, KFENCE, UBSAN, refcount, page allocation, or general protection fault messages with stack traces containing RDS functions such as rds_message_purge or RDS send paths. Also investigate unexpected loading of rds, rds_tcp, or rds_rdma modules, particularly on systems that do not normally use RDS. Because there are no public exploit indicators in the supplied data and exploitation is local, detection should focus on abnormal local process activity preceding kernel instability, sudden privilege changes after RDS-related faults, and repeated crashes with similar RDS stack traces.

• rds_message_purge
• rds_sendmsg
• net/rds
• rds.ko
• rds_tcp.ko
• rds_rdma.ko
• rds
• rds_tcp
• rds_rdma
• BUG: kernel
• WARNING: CPU:
• general protection fault
• kernel NULL pointer dereference
• KASAN:
• KFENCE:
• UBSAN:
• refcount_t:
• page allocation failure
• Oops:
• RIP: rds_message_purge
• Call Trace:
• Modules linked in: rds

What your security team should do

• Prioritize patching Linux systems that allow local user access, run untrusted workloads, host containers, or provide shared compute services.
• Inventory systems for loaded or available RDS modules and identify where RDS functionality is genuinely required.
• Deploy vendor-patched kernels and reboot hosts into the fixed kernel; track remediation by running kernel version.
• If patching is delayed, disable or blacklist unnecessary RDS modules and restrict kernel module auto-loading where feasible.
• Monitor kernel logs for RDS-related crashes, warnings, page accounting anomalies, and privilege-escalation follow-on behavior.
• Treat any local kernel crash involving RDS message purge or zerocopy send paths as potentially suspicious until reviewed.
• Watch for changes in exploit maturity, EPSS trend, distribution advisories, and any future KEV listing, because local kernel bugs can become urgent when reliable exploit code is published.