Linux kernel RDMA/irdma: data race on cqp_request->request_done during CQP completion

CVSS 9.8CVE-2023-54292Firmware, BMC & network fabriccurated

Impact

KCSAN found cqp_request->request_done read locklessly in irdma_handle_cqp_op() while irdma_cqp_ce_handler() writes it; the fix annotates both with READ_ONCE/WRITE_ONCE so the compiler cannot fuse loads. Practically this is a correctness bug in the Intel irdma RDMA driver's control-queue-pair completion path that can leave a waiter stuck or acting on a stale flag - reported from a device-teardown/module-unload path, not a tenant-reachable one. It matters on fabric-attached nodes using iWARP/RoCE via irdma, where a wedged CQP wait blocks RDMA device teardown and can require a reboot to clear, but there is no evidence here of memory disclosure or privilege gain despite the CVSS the record carries.

Who can reach it

Local and configuration-dependent: requires the irdma driver bound to Intel E810/X722 RDMA hardware, and the race was observed during RDMA device unregistration (module unload, adapter removal). Not reachable from a tenant GPU pod.

What to do

Pick up the stable kernel update with the READ_ONCE/WRITE_ONCE annotations (commits in the record); it is a kernel change, so patch and reboot the node - drain it first if it is serving RDMA traffic. Nodes without irdma-backed hardware are unaffected and need no action.

References

https://nvd.nist.gov/vuln/detail/CVE-2023-54292 https://git.kernel.org/stable/c/5986e96be7d0b82e50a9c6b019ea3f1926fd8764 https://git.kernel.org/stable/c/b8b90ba636e3861665aef9a3eab5fcf92839a2c5

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.