Linux kernel RDMA/efa: wrong teardown order lets a failed QP/CQ destroy underflow a refcount

CVSS 7.8CVE-2023-54201Firmware, BMC & network fabriccurated

Impact

The EFA RDMA driver released memory regions for a queue pair or completion queue before asking the device to destroy the object. If the device-side destroy fails, the object survives and the user or the IB core can issue destroy again, decrementing a refcount that is already zero. That underflow is a use-after-free style memory-corruption primitive in the host kernel reachable from a process that holds an EFA device file, which on a GPU node means any training job using the RDMA fabric. On multi-tenant GPU hosts the fabric device is handed to tenant workloads, so the fault domain is the whole node rather than one job. The record gives no evidence of a demonstrated exploit beyond local memory corruption, and triggering it requires the device destroy call to fail first.

Who can reach it

Local user with access to an EFA RDMA device (an /dev/infiniband verbs device), i.e. any tenant process allowed to open the fabric. No special privilege beyond that device handle; not reachable over the network and not reachable at all on nodes without EFA hardware or the efa module loaded.

What to do

Pick up the stable kernel containing the reordered deallocation (four stable branches carry the fix, see the git.kernel.org links) and reboot the node, or rebuild the out-of-tree efa module if you run the AWS driver package. There is no runtime mitigation other than denying tenants direct RDMA device access; nodes must be drained and rebooted for a kernel update.

References

https://nvd.nist.gov/vuln/detail/CVE-2023-54201 https://git.kernel.org/stable/c/24f9884971f9b34915b67baacf7350a3f6f19ea4 https://git.kernel.org/stable/c/e79db2f51a564fd4daa3e508b987df5e81c34b20

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.