Linux kernel mpi3mr driver (Broadcom tri-mode 9600-series HBA/RAID) and megaraid_sas driver: Rapidly toggling PHY

Impact

Rapidly toggling PHY enable/disable through the SAS transport sysfs interface corrupts the controller's persistent and current configuration pages on Broadcom tri-mode 9600-series adapters. The corruption is in configuration state the controller keeps, not just in kernel memory - so a host-side operation writes bad persistent state into the storage controller, which is precisely the boundary a tenant handoff is supposed to reset. The megaraid_sas sibling is a lock-ordering deadlock between reset and scan paths that hangs the SCSI host. Both are availability and integrity problems at the controller layer: a node whose controller config pages are corrupt may enumerate drives differently or fail to bring arrays up after the next reboot, and that failure surfaces on the next tenant, not the one who caused it.

Who can reach it

Local root on the bare-metal host, through the SAS transport sysfs PHY controls. On a bare-metal GPU rental this is the tenant themselves - they legitimately have root and the sysfs interface is not namespaced.

What to do

Kernel/driver update on the host and a reboot. The deeper point for operators is that this is a class you cannot patch away: a bare-metal tenant with root has a large, mostly unaudited surface of sysfs and ioctl interfaces that write persistent state into the storage controller. Between tenants, do not just reimage - re-read and, if your controller tooling supports it, restore the controller configuration to a known-good baseline (storcli/StorCLI config restore or the equivalent), and verify controller firmware version and config page integrity as part of the handoff checklist.

References