CVE-2024-43872

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:NAttack vector, network

CEQE production is driven by completions on armed CQs, which a remote RoCE peer generates directly via incoming SEND/RDMA-write-with-immediate, CM/MAD and RDMA-CM connection traffic to an RDMA-listening host (nvmet-rdma, NFS/RDMA, SMB Direct); RoCEv2 rides routable UDP/4791, so the completion flood that pins the CPU can be driven from off-segment.

AC:LAttack complexity, low

No race, no memory-layout dependency, no timing window — the attacker simply sustains a high completion rate, and the unbounded hardirq drain loop cannot exit while the hardware keeps posting entries. This was hit by ordinary heavy load in production, so deliberate flooding is entirely reliable.

PR:NPrivileges required, none

Receive completions are generated by the HCA at the queue level, before any ULP-level authentication — nvmet-rdma and NFS/RDMA post and complete receive buffers pre-auth, and RDMA-CM connection-establishment packets complete on armed CQs with no credentials at all. The alternative local path (unprivileged verbs access via world-readable /dev/infiniband/uverbs*) is only PR:L, so the unauthenticated remote path governs.

UI:NUser interaction, none

The attack is purely traffic-driven against a listening RDMA endpoint or an unprivileged local WR flood; no action by any user or administrator on the victim system is required.

S:UScope, unchanged

The CPU stall and watchdog lockup occur inside the kernel of the affected host, within the same security authority as the vulnerable driver; no VM, IOMMU, or sandbox boundary is crossed.

C:NConfidentiality impact, none

The CQN read from the CEQE is masked with num_cqs-1 before the xa_load(), so there is no out-of-bounds read and no attacker-observable data is exposed — the defect is a failure to bound loop iterations, not a memory-safety error.

I:NIntegrity impact, none

No memory is corrupted and no data is modified; the loop only consumes valid, hardware-owned queue entries and dispatches legitimate completion callbacks.

A:HAvailability impact, high

The CPU core is pinned indefinitely in hard interrupt context, producing a soft lockup with cascading RCU stalls and scheduler starvation, and the missed update_eq_db() lets the CEQ overflow into device reset; on hosts with kernel.softlockup_panic=1 (common in kdump/HA configurations) this is an outright kernel panic.