CVE-2026-46112

What it actually does

This is a local race-condition flaw in the Linux kernel HiSilicon RDMA hns_roce driver. During an error path in RDMA queue-pair creation, hns_roce_create_qp_common() can call hns_roce_qp_remove() without holding the required locks. A local attacker who can access the affected RDMA device interface may be able to trigger concurrent queue-pair cleanup and corrupt kernel memory. Depending on exploit reliability and system state, the impact may include kernel crash, data exposure, or local privilege escalation to kernel-level execution.

Why it matters to the business

Systems using affected Linux kernels with the hns_roce RDMA driver and compatible hardware may be exposed to local denial of service or privilege escalation. The practical risk is highest on shared Linux servers, HPC clusters, virtualization hosts, container hosts, and environments where untrusted or semi-trusted users can execute code and access RDMA device nodes. This issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, has very low EPSS, and has no known public exploit maturity, so broad internet-scale exploitation is unlikely; however, local kernel memory-corruption bugs can still be high impact where attacker code execution is already present.

How an attack unfolds

An attacker first obtains local code execution through a user account, compromised service, container escape prerequisite, or another foothold. They then determine whether the host has the HiSilicon RDMA hns_roce driver loaded and whether RDMA userspace device nodes such as /dev/infiniband/uverbs* are accessible. The attacker uses RDMA verbs or a custom program to repeatedly create queue pairs while forcing failures in the creation path. On vulnerable kernels, the cleanup path can invoke hns_roce_qp_remove() without the locks expected by that routine. By racing this cleanup against related queue-pair state changes, the attacker attempts to corrupt kernel memory. A failed attempt may panic the kernel; a successful attempt may allow privilege escalation, disabling of security controls, or access to sensitive kernel memory. Current available intelligence indicates no known exploitation in the wild and no known public exploit.

How to fix it

Upgrade to a Linux kernel or vendor kernel package that includes the RDMA/hns locking fix for hns_roce_qp_remove() in the queue-pair creation error path. Because no exact fixed versions were provided in the input, use the affected distribution or appliance vendor’s advisory to identify the corrected kernel build. Prioritize systems that load the hns_roce driver, expose RDMA devices to local users, or support shared workloads. If immediate patching is not possible, reduce exposure by unloading or blacklisting the hns_roce module where the hardware/functionality is not required, restricting access to /dev/infiniband/* with least-privilege permissions and device cgroup controls, limiting untrusted shell/container workloads on RDMA-capable hosts, and applying standard kernel hardening such as lockdown, module restrictions, SELinux/AppArmor policies, and rapid reboot into patched kernels after package installation.

How to confirm the fix worked

Confirm remediation by verifying the running kernel, not only the installed package, because kernel updates require reboot or kexec activation. Check vendor advisories or changelogs for the RDMA/hns fix referencing hns_roce_qp_remove(), hns_roce_create_qp_common(), or the missing-lock error path. Validate exposure by checking whether the hns_roce module is loaded with lsmod or modinfo, whether compatible RDMA hardware is present, and whether /dev/infiniband/uverbs* is accessible to non-administrative users. After remediation, confirm that the patched kernel is active with uname -a, package manager queries, and distribution-specific live-patch status if applicable. For mitigation validation, confirm that hns_roce is unloaded or blacklisted where not needed and that RDMA device node permissions prevent access by untrusted users.

Typical attack path

1. Gain local code execution on a Linux system through a valid account, compromised process, or other foothold.
2. Check whether the host uses affected Linux kernel code and whether the hns_roce RDMA driver is present or loaded.
3. Confirm access to RDMA userspace interfaces such as /dev/infiniband/uverbs* or other verbs-capable device nodes.
4. Run RDMA queue-pair creation operations designed to enter the vulnerable error-unwind path.
5. Race queue-pair cleanup/removal operations so hns_roce_qp_remove() executes without the required locking context.
6. Use the resulting kernel memory corruption to crash the system or attempt privilege escalation.
7. If privilege escalation succeeds, establish persistence, access sensitive data, or move laterally using the elevated local privileges.

How to detect it

Look for evidence of attempted local exploitation on RDMA-capable Linux hosts, especially systems with the hns_roce driver loaded. Useful sources include kernel logs, dmesg output, journald, crash dumps, kdump/vmcore artifacts, auditd logs, EDR telemetry, process execution logs, and file-access events for RDMA device nodes. Investigate kernel warnings, oopses, panics, KASAN reports, slab/list corruption, or general protection faults with call traces mentioning hns_roce_create_qp_common(), hns_roce_qp_remove(), or other hns_roce queue-pair routines. Audit unexpected processes opening /dev/infiniband/uverbs* or running RDMA test utilities from rdma-core, especially by users or services that do not normally perform RDMA operations. Because successful kernel memory-corruption exploitation may leave few clean application-level artifacts, correlate crashes or privilege changes with preceding access to RDMA device nodes, unusual local process activity, and new root-level processes or persistence created shortly after kernel instability.

• hns_roce
• hns_roce_create_qp_common
• hns_roce_qp_remove
• /dev/infiniband/uverbs
• /dev/infiniband/uverbs0
• /dev/infiniband/rdma_cm
• kernel BUG
• kernel oops
• general protection fault
• KASAN:
• slab-out-of-bounds
• use-after-free
• list_del corruption
• WARNING: CPU:
• Call Trace:
• ibv_create_qp
• ibv_rc_pingpong
• rdma_server
• rdma_client

What your security team should do

• Identify Linux systems with RDMA hardware or the hns_roce driver loaded, then prioritize those systems for kernel patching.
• Patch affected systems using vendor-provided kernel updates and reboot into the fixed kernel.
• Restrict access to /dev/infiniband/* to only users and services that require RDMA functionality.
• Where RDMA is not required, unload and blacklist the hns_roce driver to remove the vulnerable attack surface.
• Review shared compute, HPC, container, and virtualization environments first, because local privilege-escalation impact is higher when many users or workloads share a kernel.
• Monitor for kernel oops, panic, KASAN, slab corruption, or call traces involving hns_roce queue-pair functions.
• Audit unexpected use of RDMA verbs tooling or direct access to /dev/infiniband/uverbs* by non-RDMA workloads.
• Treat suspicious crashes on RDMA-capable systems as potentially security-relevant even though no public exploitation is currently known.
• Maintain compensating controls for local attacker scenarios, including least-privilege accounts, container device restrictions, and EDR/audit coverage for privileged transitions.