Linux mpi3mr: use-after-free of HBA port data when a bad drive re-reports device info

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

Impact

The mpi3mr driver, which runs the Broadcom tri-mode SAS/NVMe RAID controllers found in GPU-node and storage-node chassis, frees its internal HBA port structure when a device fails INQUIRY but leaves stale references behind. A later Device Info change event from the controller firmware touches freed memory, corrupting kernel memory and crashing the host. The practical trigger is a dying or misbehaving drive on the SAS topology rather than an attacker, but the result on a GPU node is an unplanned crash of a box whose local NVMe holds dataset and checkpoint scratch. Exploitation for privilege escalation would require control over the SAS topology, which in a datacenter means physical or firmware-level access.

Who can reach it

No network path. Requires a device on the controller's SAS topology that fails INQUIRY and then re-reports device info - in practice a failing drive, or physical access to attach one. Not reachable from a tenant GPU pod.

What to do

Patch the host kernel to a stable release containing the fix (commits linked in the record) and reboot the node; the driver cannot be reloaded safely under a live root filesystem on the same controller. Drain the node first. Only hosts using mpi3mr with SAS Transport Layer support are affected.

References

https://nvd.nist.gov/vuln/detail/CVE-2023-53037 https://git.kernel.org/stable/c/aa11e4b6cdb403b9fdef6939550f6b36dd61624d https://git.kernel.org/stable/c/8e45183978d64699df639e795235433a60f35047

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.