CVE-2026-46127

What it actually does

This vulnerability is a NULL pointer dereference in the Linux kernel RDMA ocrdma driver error-handling path, specifically in ocrdma_copy_pd_uresp(). During certain protection-domain allocation or user-response copy failures, the driver references pd->uctx before it has been initialized, causing the kernel to dereference a NULL pointer. A local user with access to the affected RDMA device interface can trigger a kernel crash, resulting in denial of service. The flaw does not directly provide confidentiality or integrity impact and is not remotely exploitable under the assigned CVSS vector.

Why it matters to the business

Successful exploitation can crash affected Linux systems that expose the vulnerable ocrdma RDMA driver to local users, causing service interruption, workload disruption, failed jobs, or node-level outages. The risk is highest on systems using Emulex/OneConnect RDMA hardware or environments where untrusted or semi-trusted local users, containers, batch jobs, or applications can access RDMA device nodes. The vulnerability is not currently listed in CISA KEV, has very low EPSS, and has no known public exploit maturity, so broad opportunistic exploitation is less likely; however, availability impact is high where the affected driver is present and reachable.

How an attack unfolds

An attacker first needs local code execution or an account on a Linux system with the vulnerable ocrdma kernel driver loaded and RDMA user interfaces accessible. The attacker then interacts with the RDMA userspace verbs interface in a way that causes ocrdma protection-domain allocation or user-response copying to enter an error path before pd->uctx has been initialized. When the vulnerable error path attempts to reference pd->uctx, the kernel dereferences a NULL pointer. This causes an oops or panic depending on kernel configuration, potentially terminating the kernel and making the host unavailable until rebooted or recovered. There is no indication from the provided data that this vulnerability is being used by named threat actors or ransomware campaigns.

How to fix it

Apply a Linux kernel update from the operating system or appliance vendor that includes the upstream fix for the RDMA/ocrdma NULL dereference in ocrdma_copy_pd_uresp(). No exact fixed package versions were provided, so administrators should consult their distribution’s kernel advisories for CVE-2026-46127 or the corresponding ocrdma fix. If immediate patching is not possible, reduce exposure by unloading or blacklisting the ocrdma module where the hardware/functionality is not required, restricting access to RDMA device nodes such as /dev/infiniband/*, limiting local shell and container access on affected hosts, and preventing untrusted workloads from accessing RDMA devices. Reboot into the patched kernel after installation, as kernel fixes are not effective until the updated kernel is running unless a validated live-patch is available.

How to confirm the fix worked

Confirm whether the ocrdma module is present or loaded using commands such as lsmod, modinfo ocrdma, and checking /sys/module/ocrdma. Verify the running kernel version with uname -a and compare it to the vendor advisory or package changelog that includes the fix. Confirm that any updated kernel is actually booted after patching. If mitigating by disabling the driver, validate that ocrdma is not loaded, that it cannot be auto-loaded, and that RDMA device nodes are not accessible to untrusted users or containers. Review kernel logs after testing or normal operation for absence of new NULL pointer dereference, oops, panic, or call traces involving ocrdma_copy_pd_uresp or the ocrdma driver.

Typical attack path

1. Obtain local access to an affected Linux system, such as a shell, compromised application context, container with RDMA device access, or legitimate low-privileged account.
2. Confirm that the ocrdma RDMA driver is present, loaded, and associated RDMA device interfaces are accessible.
3. Invoke RDMA userspace operations that reach the vulnerable ocrdma_copy_pd_uresp() error-handling path.
4. Trigger an error condition before pd->uctx is initialized.
5. Cause the kernel to dereference a NULL pointer, resulting in an oops, panic, or system crash.
6. Use the crash to disrupt services, workloads, or availability of the affected host.

How to detect it

To determine whether this issue may have already been triggered, review kernel and system logs for crashes, oops reports, panics, and call traces referencing the ocrdma driver or ocrdma_copy_pd_uresp(). Relevant sources include journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, dmesg output, persistent systemd-journald logs, kdump/vmcore records, crash dump analysis, and hypervisor or cluster-node reset events. Look for sequences where a local process interacts with RDMA interfaces shortly before a kernel NULL pointer dereference. Correlate kernel crash timestamps with auditd logs, shell history where available, container runtime events, batch scheduler jobs, RDMA verbs utilities, and access to /dev/infiniband/* device nodes. Because this flaw causes a crash rather than writing a durable artifact, evidence may be limited to pre-crash logs or crash dumps. There are no known threat-actor-specific indicators from the provided intelligence.

• ocrdma_copy_pd_uresp
• ocrdma
• NULL pointer dereference
• BUG: kernel NULL pointer dereference
• Unable to handle kernel NULL pointer dereference
• Kernel panic - not syncing
• Oops:
• /sys/module/ocrdma
• /dev/infiniband/
• module ocrdma
• Call Trace:
• RIP: ocrdma_copy_pd_uresp

What your security team should do

• Inventory Linux systems with RDMA hardware or loaded ocrdma kernel modules and prioritize those allowing local multi-user, container, HPC, or batch workload access.
• Patch affected systems using vendor-supported kernel updates and reboot into the fixed kernel as soon as operationally feasible.
• Where ocrdma is not required, blacklist or unload the module and confirm it cannot be auto-loaded.
• Restrict permissions and device passthrough for /dev/infiniband/* and related RDMA interfaces to only trusted users and workloads.
• Review recent kernel logs for oops, panic, NULL pointer dereference, or call traces involving ocrdma_copy_pd_uresp as potential evidence of attempted or accidental triggering.
• Add monitoring for unexpected ocrdma module loading and kernel crashes on systems where RDMA is not expected.
• Treat exploitation risk as primarily local availability impact, but prioritize remediation on critical compute, storage, virtualization, or clustered nodes where a crash would cause operational disruption.