Solidigm DC SSD firmware - unauthorized access to a LOCKED storage device via improper resource management: An attacker

Impact

An attacker with local or physical access gains unauthorized access to a drive that is in the locked state; the paired issue additionally allows denial of service. 'Locked' is the state your decommission and reclaim runbooks rely on - the drive is supposed to be an inert brick until someone presents the credential. BREAKS TENANT HANDOFF: a drive locked at the end of a tenancy, or locked before shipping back on RMA, can be read anyway. The DoS variant additionally gives a tenant a way to take a drive out from under the host, which on a shared bare-metal node is a self-service outage. These are the most recent public confirmations that the locked-drive guarantee keeps failing on datacenter NVMe - four separate CVEs across two advisory cycles on the same product family.

Who can reach it

A tenant with local (host-level, elevated) access on the bare-metal machine, or anyone with physical access to the drive after it leaves the rack - RMA courier, decommission handler, resale buyer.

What to do

Firmware update from Solidigm's security page for the affected DC SKUs; drive offline, node drained, Solidigm Storage Tool per SKU. Check your own inventory against the advisory rather than assuming coverage, because Solidigm's DC line spans many families with different firmware trains and older SKUs in this same advisory family have previously been marked no-fix. The structural lesson for an operator: this is now the fourth-plus distinct 'locked drive is not actually locked' finding on datacenter NVMe in two years, so budget for it as a recurring class rather than a one-off patch - assume drive-level locking will fail again and keep a software encryption layer (LUKS/dm-crypt, operator-held key) as the control that actually enforces tenant separation.

References