Linux Kernel CVE-2026-72494

Exploitation requires the irdma driver to be loaded, which in practice means the system has an Intel Ethernet RDMA-capable adapter and RDMA/RoCE enabled - this is the specific configuration prerequisite, not a default on general-purpose servers. The attacker must also be able to drive concurrent irdma request/response activity to hit the narrow race window between the waiter and the completion signal. Limiting factors: it is a local, timing-sensitive data race (not remotely reachable despite the AV:N in the supplied vector), it only affects hosts that actually run irdma, and hitting the window reliably is non-trivial; authentication requirements are not confirmed from available data because the supplied PR:N conflicts with the local nature of the defect.

The signals conflict sharply and the raw CVSS should not be trusted at face value. The provided CVSS:3.1 vector (AV:N/AC:L/PR:N/UI:N, 9.8) describes remote unauthenticated total compromise, but the actual change is a local race in an optional hardware driver - verify with vendor, as the network vector almost certainly reflects automated bulk-scoring of kernel CVEs rather than a real remote path. Corroborating signals point the other way: EPSS is only 0.16% (6th percentile), there is no KEV listing, and no public exploit exists, which is consistent with a hard-to-hit timing bug rather than a weaponizable RCE. The 'Information Disclosure' tag is also unconfirmed by the description, which describes a synchronization fix with no stated disclosure primitive. Realistic impact is most likely local denial of service (hang or crash) or memory-safety issues on systems that actually run RDMA over Intel NICs - a narrow, datacenter/HPC-leaning population. Prioritization should therefore be routine kernel patching for RDMA-enabled hosts rather than emergency response; a team running Intel RDMA fabrics should fold the fix into its next maintenance window, while hosts without the irdma module loaded face effectively no exposure.

On a host with the irdma module loaded and an Intel RDMA-capable NIC, a local process or concurrent kernel workload repeatedly issues irdma control operations to widen the unsynchronized request_done window, aiming to make a waiter act on a stale flag or a missed wake-up. Success most plausibly yields a kernel hang, crash, or memory-state corruption rather than clean code execution. No proof-of-concept is publicly known, and the race is timing-dependent, making reliable exploitation difficult.