Crucial/Micron MX100, MX200, MX300; Samsung 840 EVO and 850 EVO (ATA-high mode)

Impact

The drive's data-encryption key is not derived from the password at all. Set an ATA password or an Opal credential, and the drive still encrypts with a key that sits in the controller independent of that secret - so anyone who can talk to the firmware recovers the plaintext without ever knowing the password. BREAKS TENANT HANDOFF: an operator who 'securely wipes' a node by setting/resetting a drive password, or who relies on the SED to make old data unreadable, has done nothing. The next tenant who gets that bare-metal box, or anyone who receives the drive on an RMA or decommission pallet, reads the prior tenant's training data, checkpoints, SSH keys and cloud credentials in the clear. It also means your 'crypto erase' is not a crypto erase - the key you thought you threw away was never the key protecting the data.

Who can reach it

Anyone who obtains the drive and can issue vendor/debug commands to its controller: the next tenant on the same bare-metal host, an RMA return path, a decommissioned node in a resale channel, or a rack tech with five minutes and a SATA cable. No password, no user credential, and no network access needed - physical or low-level bus access to the drive is the whole requirement.

What to do

Treat as UNPATCHABLE in practice on the affected SKUs - these are consumer/prosumer drives, several vendors never shipped a firmware fix, and the flaw is in how the key hierarchy was designed rather than a bounds check. The real fix is a policy change: stop trusting hardware encryption as your tenant-separation boundary and layer software encryption you control (LUKS/dm-crypt with a key held in your KMS, or per-tenant filesystem encryption) on top of every local NVMe/SATA device. Then 'crypto erase between tenants' means destroying a key you own, which is verifiable, instead of asking the drive to forget something. Also disable Windows eDrive/BitLocker hardware offload fleet-wide (see the ADV180028 entry). For drives already in service: re-provision with software encryption requires a full re-image and re-encrypt of every affected node, and any drive that held sensitive data before the policy change should be physically destroyed rather than resold, because you cannot retroactively prove it was erased.

References