Solidigm DC SSDs (D3-S4510/S4520/S4610/S4620, D5-P5316, D7-P5520/P5620, DC S4500/S4600)

Impact

A defect in how the drive handles its over-provisioned capacity leaks data to an attacker. Over-provisioned blocks are the spare NAND the FTL keeps outside the host-visible LBA range - they hold real tenant data that was written and then remapped, and they are invisible to every host-side wipe. BREAKS TENANT HANDOFF: dd-over-the-whole-device, blkdiscard, mkfs and any 'overwrite the visible address space' routine cannot reach these blocks by construction, so a previous tenant's data survives a reclaim that looks completely thorough from the host. This is the concrete, CVE'd instance of the general wear-levelling problem operators are usually told about only in the abstract.

Who can reach it

A tenant with local/root access on the bare-metal host after reclaim, reading back data the previous tenant wrote. Low privilege required on the host; no physical access needed.

What to do

Firmware flash, per SKU, drive offline: ACV10340 for D5-P5316, XCV10151/XC311151 for D3-S4510/S4610, 7CV10111 for D3-S4520/S4620, 9CV10410 for D7-P5520/P5620, YCV10200 for D5-P5530, applied with Solidigm Storage Tool. Note the sting in the advisory: for DC S4500 and DC S4600 Solidigm states it has NO plans to ship a fix unless a customer explicitly requests one - on those SKUs this is effectively UNPATCHABLE, and the only safe reclaim is physical destruction or accepting that host-side wipes do not cover OP blocks. Because no host-side tool can reach over-provisioned NAND, the durable control is again encryption you own: LUKS/dm-crypt per tenant with the key in your KMS, so remapped ciphertext in OP blocks is worthless after you delete the key. Flashing a 10,000-drive fleet is a rolling drain across weeks with per-SKU tooling and per-SKU firmware images; expect the inventory step (working out which of five Solidigm families each node actually has) to take as long as the flashing.

References