CVE-2026-63860

What it actually does

CVE-2026-63860 is an improper input validation flaw in the Linux kernel RDMA core netlink handling. Certain RDMA netlink attributes were defined as NLA_STRING and later treated as C strings, including use in strcmp-style comparisons and %s-style formatting. NLA_STRING does not require a trailing null byte, so a local caller can provide a malformed attribute without a NUL terminator and cause kernel code to read beyond the supplied attribute buffer. Depending on memory layout and execution path, this can lead to kernel out-of-bounds reads, information disclosure, kernel crash, or potentially corruption-sensitive behavior that could support local privilege escalation. The upstream fix changes the affected attributes to NLA_NUL_STRING so the kernel enforces proper null termination before the values are consumed as strings.

Why it matters to the business

The practical risk is highest on Linux systems where RDMA functionality is enabled or available to local users, including high-performance computing, storage, virtualization, database, and low-latency networking environments. A local attacker or compromised low-privilege workload may be able to destabilize the host, expose sensitive kernel memory, or potentially gain elevated privileges. The vulnerability is not listed in CISA KEV, has no known mature public exploit at the time of the provided data, and has a low EPSS score, which lowers immediate internet-scale exploitation concern; however, the CVSS score is high because successful exploitation could affect confidentiality, integrity, and availability of the host.

How an attack unfolds

An attacker first needs the ability to execute code locally on a vulnerable Linux system or otherwise send RDMA-related netlink messages from a local context. They then craft a netlink request containing an RDMA attribute that is accepted as NLA_STRING but intentionally omits the terminating null byte expected by later kernel code. When the RDMA core processes the message, it passes the attribute value to string-handling logic that assumes a valid C string. The kernel may continue reading beyond the end of the attribute until it encounters a null byte elsewhere in memory. This can produce an out-of-bounds read, kernel warning or panic, information exposure through logs or returned data, or, in more severe cases, contribute to a privilege-escalation chain. Exploitation is local rather than remotely network-triggered and depends on the affected kernel build, RDMA subsystem availability, module configuration, and reachable RDMA netlink operations.

How to fix it

Upgrade to a Linux kernel version that includes the RDMA/core fix changing the affected attributes from NLA_STRING to NLA_NUL_STRING. Because fixed package versions were not provided in the input, use the security advisory and kernel package guidance from the relevant Linux distribution or kernel vendor, and prioritize kernels containing the upstream RDMA/core null-string validation patch. After updating, reboot into the fixed kernel and confirm the running kernel is the patched version, not merely installed on disk. Where immediate patching is not possible, reduce exposure by disabling or unloading unused RDMA-related kernel modules and services, restricting local shell access, limiting untrusted workload execution on systems with RDMA enabled, applying least privilege to users and containers, and monitoring for abnormal RDMA netlink activity or kernel crashes. Avoid relying on network perimeter controls alone because exploitation is local.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel includes the RDMA/core NLA_NUL_STRING fix from the vendor or upstream stable branch. Check the active kernel with uname -r and compare it against the distribution’s fixed kernel package advisory. Where source or build metadata is available, confirm that the relevant RDMA netlink attribute policies use NLA_NUL_STRING rather than NLA_STRING for attributes later consumed as C strings. Validate that the system has rebooted into the updated kernel. If RDMA is not required, confirm that RDMA modules are not loaded and that RDMA tooling is not available to untrusted users. For exposure assessment, inventory Linux hosts with RDMA hardware, ib_core/rdma_cm modules, or RDMA user-space tools installed, then prioritize patch validation on those systems.

Typical attack path

1. Obtain local code execution on a vulnerable Linux host, such as through a compromised user account, container escape prerequisite, or malicious local process.
2. Check whether RDMA kernel components, libraries, or devices are present and whether RDMA netlink interfaces are reachable.
3. Construct a malformed RDMA netlink message containing a string attribute without a trailing null byte.
4. Send the crafted message to the kernel through the local netlink interface.
5. Trigger RDMA core code paths that compare or print the attribute as a C string.
6. Cause an out-of-bounds kernel read, potentially resulting in kernel crash, memory disclosure, or behavior useful for further local privilege escalation.
7. Use any gained information or instability to support broader compromise, persistence, or denial of service.

How to detect it

There is no highly reliable, CVE-specific exploitation artifact from the provided information. Detection should focus on evidence of local abuse and kernel instability around RDMA netlink processing. Review kernel logs from journald, dmesg, /var/log/kern.log, /var/log/messages, and crash dump infrastructure for oops, panic, general protection fault, KASAN, slab out-of-bounds, or warning events involving RDMA-related modules or netlink handlers. Correlate those events with local process execution, user logins, container activity, and invocation of RDMA utilities shortly before the crash or warning. Audit logs may show suspicious execution of RDMA tooling or custom binaries by low-privilege users. On systems with kernel crash dumps enabled, inspect vmcore data for stack traces involving RDMA core, ib_core, rdma_cm, nl802/netlink-style attribute parsing, or string comparison/formatting paths. Because exploitation is local, network telemetry alone is unlikely to show the attack; endpoint and kernel telemetry are the primary sources.

• ib_core
• rdma_cm
• rdma_nl_rcv
• rdma_nl_rcv_msg
• general protection fault
• BUG: kernel NULL pointer dereference
• KASAN: slab-out-of-bounds
• KASAN: global-out-of-bounds
• kernel panic
• Oops:
• NETLINK_RDMA
• /var/crash/vmcore
• /proc/modules

What your security team should do

• Prioritize patching Linux systems with RDMA enabled, RDMA hardware present, or workloads that allow local execution by untrusted users.
• Track the relevant Linux distribution advisories and update to a kernel build that contains the RDMA/core NLA_NUL_STRING validation fix; reboot after installation.
• Inventory systems with loaded RDMA-related modules such as ib_core, rdma_cm, iw_cm, or mlx/irdma provider drivers to identify higher-risk exposure.
• If RDMA is not operationally required, disable or unload RDMA modules and remove unnecessary RDMA user-space packages where feasible.
• Harden local execution paths by restricting interactive access, tightening container isolation, and limiting untrusted workloads on shared Linux hosts.
• Monitor kernel logs for crashes, warnings, or oops events involving RDMA, netlink, ib_core, or rdma_cm components.
• Treat unexplained local kernel crashes on RDMA-capable systems as potentially security-relevant until patched and investigated.
• Because this is not currently KEV-listed and has low EPSS, schedule according to normal high-severity kernel patch SLAs, but accelerate for multi-tenant, shared compute, HPC, storage, and virtualization platforms.