CVE-2025-38582

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:LAttack vector, local

The defect lives in the hns_roce HIP08 device init/re-init path (`__hns_roce_hw_v2_init_instance()` → `free_mr_init()`), reached via driver probe, module load, or the hns3 NIC reset-recovery notifier — never from remote packet data. Reaching or influencing it requires local access to the machine (RDMA uverbs devices, memory/resource pressure, or a locally initiated reset).

AC:LAttack complexity, low

The double destruction fires whenever `free_mr_alloc_res()` fails partway through creating the 8 reserved QPs, since the `create_failed_qp` unwind kfree()s `free_mr->rsv_qp[i]` without NULLing the array slot, leaving dangling pointers that `hns_roce_v2_exit()` → `free_mr_exit()` destroys and frees a second time. A local attacker can influence exactly that partial-failure window by driving slab/QP/CQ/PD resource exhaustion so one of the eight allocations fails after earlier ones succeeded, and the init/reset sequence is repeatable, so the required conditions are not beyond the attacker's control.

PR:LPrivileges required, low

No authentication beyond ordinary local access is needed to create the precondition — an unprivileged user holding the usual `/dev/infiniband/uverbs*` access in an RDMA deployment can exhaust QP/CQ/PD and memory resources to make the reserved-resource allocation fail mid-loop. The init/reset trigger itself is not gated by any capability check inside the vulnerable code path.

UI:NUser interaction, none

The faulty unwind executes automatically inside the driver's own error path during device initialization or NIC reset recovery. No victim has to open a file, mount anything, or take any other action.

S:UScope, unchanged

The corrupted objects (`struct hns_roce_qp`, its lists and the kernel slab) all belong to the kernel's own security authority. There is no crossing into a hypervisor, IOMMU, or other separate security scope.

C:HConfidentiality impact, high

The second `hns_roce_v2_destroy_qp()` operates entirely on freed memory — it reads `hr_qp->ibqp.send_cq`/`recv_cq` and passes them to `to_hr_cq()`/`__hns_roce_v2_cq_clean()`, and uses `hr_qp->qpn` for `__xa_erase()`. If the reclaimed slab object is groomed by the attacker, those become fully controlled pointers, yielding an arbitrary kernel-memory read primitive.

I:HIntegrity impact, high

`hns_roce_qp_remove()` performs three `list_del()` unlinks on the freed object, each writing `prev->next = next; next->prev = prev` with pointers taken from reclaimed slab memory — a classic controlled-write primitive — and the object is then kfree()d a second time, corrupting the freelist. That combination is exploitable for control-flow hijack and privilege escalation.

A:HAvailability impact, high

The reported failure is an immediate `list_del corruption ... LIST_POISON1` WARNING in `__list_del_entry_valid()` from `hns_roce_qp_remove()`, and the double kfree() corrupts the slab allocator. This reliably produces an oops/panic and leaves the RDMA device unusable.