Solidigm DC SSDs with TCG Opal (DC P4510/P4511/P4610 Opal, D5-P4320/P4326 Opal, D5-P5316 Opal, D7-P5510/P5520/P5620

Impact

The firmware mishandles the REMOVAL of access - that is, revocation does not fully take effect. An authorization that should have ended when you deprovisioned the drive can still be usable. BREAKS TENANT HANDOFF precisely at the moment of handoff: the step where you revoke the previous tenant's access to a locking range is the step that fails, so credentials or authority granted to the departing customer keep working against the drive. Distinct from the access-control-validation bug on the same SKUs, and worth tracking separately because the failure is in de-provisioning rather than in the initial check - it is invisible to any test that only verifies that locking works when you set it up.

Who can reach it

An attacker with physical access to the drive plus some low-level privilege - realistically a departing tenant who retained drive credentials from their tenancy, or anyone who later obtains the physical media through RMA or decommission.

What to do

Firmware flash, per SKU, drive offline via Solidigm Storage Tool - same firmware trains as the sibling Opal issue (VEV10294/VDV10194/VCV10394 for P4510/P4511/P4610 Opal, 3DV10132 for D5-P4320 Opal, 8DV10564 for D5-P4326 Opal, ACV10340 for D5-P5316 Opal, JCV10404 for D7-P5510, 9CV10410 for D7-P5520/P5620 Opal). Operationally, add a verification step your reclaim pipeline probably lacks: after revoking a locking range, actively re-test that the old credential is rejected, rather than assuming revocation succeeded because the command returned success. And do not let Opal credentials be the only thing standing between two customers - a per-tenant LUKS key you destroy at reclaim is revocation you can actually prove.

References