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

Impact

Improper access-control validation in the Opal-enabled firmware lets an attacker with physical access gain unauthorized access to the drive, or a local attacker knock it offline. The highest-scored entry in Solidigm's 2024 advisory set, and it hits exactly the SKUs an operator chose specifically BECAUSE they are Opal drives - the ones bought so that locking ranges would separate tenants and make decommissioning safe. BREAKS TENANT HANDOFF: the locking that your reclaim process depends on can be walked around, so a drive you believed was cryptographically locked between customers is readable. Also carries an availability tail - a local attacker can take the drive down, and on a shared bare-metal node that is a tenant-triggered outage.

Who can reach it

An attacker with physical access to the drive - the RMA return path, a decommissioned node in the resale channel, or a colo/rack tech - for the unauthorized-access half; a tenant with local access on the host for the denial-of-service half.

What to do

Firmware flash per SKU with drive offline and node drained, using Solidigm Storage Tool: VEV10294/VDV10194/VEV10394 for the P4510/P4511/P4610 Opal variants, 3DV10132 for D5-P4320 Opal, 8DV10564 for D5-P4326 Opal, ACV10310 for D5-P5316 Opal, JCV10300 for D7-P5510 Opal, 9CV10410 for D7-P5520/P5620 Opal. Stop treating an Opal locking range as your tenant boundary on its own - it is a vendor-attested control you cannot audit. Layer LUKS/dm-crypt above it so a locking-range bypass yields ciphertext. Chain-of-custody matters as much as the flash here: because the attack is physical, tighten RMA and decommission handling (destroy rather than return where contract allows, or degauss/shred media that held tenant data) - a firmware update on drives still in the rack does nothing for the ones already on a pallet heading back to the vendor.

References