CVE-2026-43494

What it actually does

This is a Linux kernel memory-corruption flaw in the RDS networking subsystem. When RDS zero-copy send handling fails while pinning user pages, the kernel releases the pages and clears the zero-copy notifier, but leaves the message entry count, op_nents, nonzero. A later cleanup path in rds_message_purge() treats those entries as still valid and attempts to free them again, creating a double-free condition. Because the bug is reachable from a local send path and has CVSS characteristics of AV:L/AC:L/PR:L/UI:N with high confidentiality, integrity, and availability impact, a local authenticated user may be able to crash the kernel or potentially escalate privileges through kernel memory corruption, depending on kernel configuration, allocator behavior, and exploit reliability.

Why it matters to the business

Successful exploitation can compromise the stability and trust boundary of Linux systems by allowing a local user or compromised application account to trigger a kernel crash or potentially gain elevated privileges. Operationally, this can lead to host outages, workload disruption, container or multi-user isolation failure, and increased risk where untrusted users, shared compute, CI runners, bastion hosts, or containerized workloads run on affected kernels. The vulnerability is not currently listed in CISA KEV, has no reported ransomware association, and has low EPSS at this time, but kernel local privilege-escalation bugs should still be prioritized on systems where attackers may already have limited local code execution.

How an attack unfolds

An attacker first needs local access to an affected Linux system with sufficient ability to invoke the vulnerable RDS send path. The attacker prepares an RDS message using zero-copy behavior and deliberately causes the page-pinning operation in rds_message_zcopy_from_user() to fail. During that failure path, the kernel releases pages but leaves an internal entry counter set. When rds_sendmsg() later triggers message cleanup, rds_message_purge() iterates over the stale entry count and frees objects that were already released. In the simplest outcome, this causes kernel memory corruption and a system crash. With additional heap shaping and kernel-specific exploitation work, the same double-free primitive may be used to corrupt kernel memory in a controlled way and potentially execute code with kernel privileges.

How to fix it

Upgrade the Linux kernel to a vendor release that includes the upstream fix resetting op_nents when zero-copy page pinning fails in net/rds. Because fixed_versions were not provided in the input, use the security advisory and package metadata from the relevant distribution or kernel provider to identify the corrected kernel build. After upgrading, reboot into the fixed kernel and remove older vulnerable kernels where operationally feasible. If immediate patching is not possible, reduce exposure by disabling or preventing loading of the RDS kernel module where it is not required, limiting local shell access, restricting untrusted workloads, enforcing least privilege, and applying kernel hardening controls such as lockdown, module-loading restrictions, SELinux/AppArmor policy, and container isolation. Mitigations should be treated as temporary because they do not correct the faulty cleanup logic.

How to confirm the fix worked

Confirm remediation by verifying that systems are running a kernel package from the distribution or vendor advisory that contains the net/rds fix for resetting op_nents in rds_message_zcopy_from_user(). Validate with package manager output, kernel version inventory, and reboot status checks to ensure the active running kernel is the fixed kernel rather than only an installed but inactive package. Review whether the rds module is present or loaded using standard module inventory commands, and confirm any mitigation prevents unnecessary RDS module loading. For source-built kernels, confirm that the patched net/rds code resets op_nents on the iov_iter_get_pages2() failure path before message purge can occur.

Typical attack path

1. Obtain low-privileged local access to an affected Linux host, such as through a shell, compromised service account, container escape precondition, or shared-user environment.
2. Determine whether the affected kernel includes the vulnerable RDS implementation and whether RDS functionality is available or loadable.
3. Trigger RDS zero-copy send behavior through the local networking interface or socket path.
4. Force iov_iter_get_pages2() to fail during rds_message_zcopy_from_user() after partial page handling.
5. Allow the send-message cleanup path to run, causing rds_message_purge() to process a stale nonzero op_nents value.
6. Exploit the resulting double-free as a denial of service or attempt kernel memory corruption for privilege escalation.

How to detect it

Detection should focus on evidence of attempted or successful triggering of the RDS zero-copy failure path and subsequent kernel memory corruption. Review kernel logs from journald, syslog, dmesg, crash dumps, and centralized logging for RDS-related stack traces, double-free warnings, slab allocator corruption, bad page state messages, kernel oopses, general protection faults, and panics that reference rds_message_zcopy_from_user(), rds_message_purge(), rds_sendmsg(), iov_iter_get_pages2(), or net/rds. Check module and socket usage telemetry for unexpected loading of the rds module or unusual RDS socket activity on systems that do not normally use RDS. If a crash occurred, preserve vmcore/kdump artifacts and correlate the time of failure with local process execution, recent user logins, container activity, suspicious binaries in temporary directories, and audit logs showing module loads or unusual socket creation. Because no public exploit maturity or named threat actor activity is provided and this is not currently KEV-listed, absence of known exploit IOCs does not rule out exploitation; rely on behavioral crash artifacts and local activity correlation.

• rds_message_zcopy_from_user
• rds_message_purge
• rds_sendmsg
• iov_iter_get_pages2
• net/rds
• BUG: Bad page state
• BUG: unable to handle page fault
• kernel BUG at
• Oops:
• general protection fault
• double free
• use-after-free
• slab corruption
• KASAN: double-free
• KASAN: use-after-free
• RDS

What your security team should do

• Prioritize patching Linux systems that allow local user access, run untrusted workloads, host containers, provide shared development or CI services, or process externally supplied code.
• Inventory affected Linux kernel versions across servers, appliances, cloud images, containers hosts, and golden images; ensure the active running kernel is updated after reboot.
• If RDS is not operationally required, disable or block loading of the rds kernel module until patched.
• Monitor kernel logs for crashes or warnings involving rds_message_zcopy_from_user(), rds_message_purge(), double-free, bad page state, slab corruption, or general protection faults.
• Treat unexplained kernel crashes on multi-user systems as potential security events and preserve logs, vmcores, and recent process execution data for investigation.
• Apply compensating controls for local privilege escalation risk, including limiting interactive access, tightening sudo boundaries, strengthening container isolation, and restricting kernel module loading.
• Track vendor advisories for exact fixed package versions and incorporate the fix into base images and patch compliance reporting.