Intel / Solidigm SSD, SSD DC and Optane SSD firmware

CVSS 4.6CVE-2021-33082Firmware, BMC & network fabricINTEL-SA-00563Solidigm SA-000563curated

Impact

Sensitive data is not removed before the media is reused. The drive accepts an NVMe Sanitize with Block Erase, reports completion, and leaves the previous contents recoverable. BREAKS TENANT HANDOFF in the most direct way in this whole category: this IS the command most bare-metal reclaim pipelines issue between customers. Your automation records a successful sanitize, the node goes back into the pool, and the next tenant can carve the previous tenant's datasets, model checkpoints and any credentials that touched local scratch out of the flash. Worse, it fails clean - there is no error to alert on, so a fleet can run in this state for years and every audit log says the erase succeeded.

Who can reach it

The next tenant with root on the reclaimed bare-metal host, or anyone who obtains the physical drive later (RMA, decommission, resale). The attacker does not need to break anything - they read what the sanitize left behind.

What to do

Two moves, do both. (1) Immediate policy/workaround, no downtime: stop using Sanitize with Block Erase (SANACT=04h in the Sanitize command's block-erase form) in your reclaim path and switch to Sanitize with Crypto Erase, or Format NVM with Crypto Erase / User Data Erase - this is the vendor's own prescribed workaround and it is a one-line change in most reclaim scripts, so ship it today. (2) Flash affected drives to fixed firmware; this needs the drive quiesced, usually a node drain, and Solidigm Storage Tool / Intel MAS with per-SKU firmware images, so plan it as a rolling maintenance campaign. Note that several older SKUs in the same advisory family are explicitly end-of-support with no fix planned unless a customer asks - for those, the workaround IS the remediation. Independently: layer LUKS/dm-crypt with an operator-held key on all tenant-visible local NVMe, so reclaim means destroying your key rather than trusting the drive's report. Verifying erase across a 10,000-drive fleet by actually reading back raw blocks is a weeks-long operation and essentially no operator does it - which is precisely why a firmware that lies about sanitize success goes undetected.

References

https://nvd.nist.gov/vuln/detail/CVE-2021-33082 https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00563.html https://www.solidigm.com/support-page/support-security.html https://www.solidigm.com/content/dam/solidigm/en/site/support/support-community/cve-(security)/documents/public-security-advisory-v2.pdf

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.