CVE-2026-64033

What it actually does

This is a Linux kernel use-after-free vulnerability in the RDMA RTRS server path setup error handling. During rtrs_srv_create_path_files(), if sysfs root folders and a kobject have been initialized but a later creation step fails, cleanup can call kobject_put(&srv_path->kobj) first. If that drops the final reference, rtrs_srv_release() frees srv_path, and the subsequent rtrs_srv_destroy_once_sysfs_root_folders(srv_path) dereferences freed memory. In kernel context, a use-after-free can cause a crash and, depending on allocator state and attacker control over timing or heap reuse, may allow privilege escalation or arbitrary kernel memory corruption. The assigned network, unauthenticated CVSS vector indicates the vulnerable path may be reachable remotely where RTRS/RDMA services are exposed and configured.

Why it matters to the business

Systems using the Linux kernel RDMA RTRS server functionality could be crashed or potentially compromised through a remotely reachable kernel memory corruption flaw. The most immediate operational risk is denial of service on storage or RDMA-backed workloads, but the severity is high because successful exploitation of kernel memory corruption can also lead to full host takeover. Although the current EPSS score is low and there is no CISA KEV listing or known ransomware association, kernel vulnerabilities in remotely exposed infrastructure should be treated as high priority, especially in environments using RDMA, RTRS, or related high-performance storage fabrics.

How an attack unfolds

An attacker targets a Linux system with RDMA RTRS server functionality enabled and reachable. They initiate or influence RTRS path creation in a way that causes rtrs_srv_create_path_files() to partially initialize sysfs/kobject state and then fail at a later step. The vulnerable cleanup sequence releases the kobject before removing related sysfs root folders. If the kobject reference count reaches zero, the release callback frees the srv_path object. Cleanup then continues and dereferences the already-freed srv_path pointer. In the simplest case, this triggers a kernel oops or panic and disrupts the host. A more advanced attacker would attempt to shape kernel heap allocation and object reuse around the freed srv_path memory so that the stale dereference corrupts controlled data or redirects kernel behavior, potentially leading to code execution in kernel context.

How to fix it

Upgrade to a Linux kernel version that contains the RDMA/rtrs fix which destroys sysfs root folders before calling kobject_put(&srv_path->kobj) in the rtrs_srv_create_path_files() error path. If using a distribution kernel, apply the vendor-provided security update rather than attempting to cherry-pick upstream changes unless your organization maintains custom kernels. No exact fixed package versions were provided in the input, so track advisories from the relevant Linux distribution or kernel supplier for this CVE. As temporary mitigation, disable or unload RTRS/RDMA server functionality where it is not required, restrict RDMA/RTRS network exposure to trusted management or storage networks, and block untrusted access to RDMA-capable interfaces. For custom kernels, confirm the cleanup order in the RDMA/rtrs server code has been changed so rtrs_srv_destroy_once_sysfs_root_folders(srv_path) occurs while srv_path remains valid, before the final kobject_put().

How to confirm the fix worked

Confirm the running kernel includes the vendor fix by checking the installed kernel package version against the distribution advisory for this issue. On custom kernels, inspect the RDMA/rtrs patch or source code to verify that the sysfs root folders are destroyed before kobject_put(&srv_path->kobj) in the rtrs_srv_create_path_files() error path. Validate whether exposure exists by checking whether RTRS/RDMA kernel modules are present or loaded and whether RDMA-capable services are reachable from untrusted networks. After patching, reboot into the fixed kernel and confirm with uname -a and package-manager queries that the active kernel is the updated one. Where possible, run regression tests for RTRS/RDMA storage path creation and teardown, and review kernel logs for absence of KASAN, slab, general protection fault, or kernel oops messages involving RDMA/rtrs code.

Typical attack path

1. Identify Linux hosts exposing RDMA/RTRS-related services or storage fabric interfaces.
2. Establish network reachability to the RDMA/RTRS service path without requiring local user interaction.
3. Trigger RTRS server path file creation while inducing a later failure in rtrs_srv_create_path_files().
4. Cause the vulnerable cleanup order to call kobject_put() before sysfs root folder destruction.
5. Force or wait for kobject reference release so rtrs_srv_release() frees the srv_path object.
6. Rely on the subsequent cleanup call to dereference the freed srv_path pointer.
7. Achieve denial of service through kernel crash, or attempt heap manipulation for kernel memory corruption and possible privilege escalation.

How to detect it

Look for evidence of prior exploitation primarily in kernel and system logs, crash dumps, and RDMA/RTRS service telemetry. Relevant sources include dmesg, journald, /var/log/kern.log, /var/log/messages, /var/log/syslog, kdump/vmcore artifacts, kernel oops reports, KASAN reports, and monitoring alerts for unexpected host reboots or panics. Search for crashes or memory safety diagnostics involving RTRS, RDMA, rtrs_srv_create_path_files(), rtrs_srv_destroy_once_sysfs_root_folders(), rtrs_srv_release(), kobject_put(), or sysfs path creation. Also correlate any kernel crash with inbound RDMA/RTRS connection attempts or storage path setup activity immediately before the event. Since this vulnerability is in an error cleanup path, exploitation may appear as failed path creation followed by a use-after-free, general protection fault, slab corruption, NULL or invalid pointer dereference, kernel panic, or sudden reboot. Absence of these artifacts does not prove non-exploitation, because a successful kernel memory corruption exploit may avoid obvious crashes.

• KASAN: use-after-free
• BUG: KASAN: use-after-free
• use-after-free in rtrs_srv_create_path_files
• rtrs_srv_create_path_files
• rtrs_srv_destroy_once_sysfs_root_folders
• rtrs_srv_release
• RDMA/rtrs
• rtrs_srv
• kobject_put
• general protection fault
• kernel BUG
• Oops:
• Kernel panic
• slab-use-after-free
• BUG: unable to handle kernel paging request
• sysfs: cannot create duplicate filename
• rtrs

What your security team should do

• Prioritize patching Linux hosts that use RDMA, RTRS, rnbd/rtrs, or high-performance storage fabrics, especially if reachable over a network.
• Inventory systems with RDMA-capable interfaces and loaded RTRS-related kernel modules.
• Restrict RDMA/RTRS access to trusted storage networks; do not expose these services to general user, data center, or internet-reachable networks.
• Apply vendor kernel updates and reboot promptly so the fixed kernel is active, not merely installed.
• For systems where RTRS is unused, disable or unload the relevant modules and prevent them from autoloading.
• Enable or review kernel crash, kdump, and centralized syslog collection so kernel oops/panic evidence is retained.
• Monitor for kernel warnings, KASAN reports, slab corruption, or crashes referencing rtrs_srv_create_path_files, rtrs_srv_release, or RDMA/rtrs.
• Because there is no current KEV listing, known ransomware use, or public exploit maturity in the supplied data, focus urgency on exposed RDMA/RTRS systems rather than broad emergency response across all Linux hosts.