Database/Firmware, BMC & network fabric

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
Related entries
- Arm Neoverse V2 / V3 / V3AE, Cortex-X3 / X4 / X925, C1-seriesCVE-2024-7881 · Arm Neoverse V2 / V3 / V3AE, Cortex-X3 / X4 / X925, C1-series; mitigated in Trusted Firmware-A v2.2-v2.12 and LTS…Medium
- Junos Space: stored XSS in management UI pages lets an attacker run actions as a logged-in administratorCVE-2025-59990 · Juniper Junos Space (template creation and report generation pages)Medium
- NVIDIA UFM Enterprise: hard-coded key in session management allows information disclosure and privilege escalationCVE-2026-24166 · NVIDIA UFM Enterprise (session management, hard-coded cryptographic key)Medium
- IBM PowerVM PKS and virtual TPM: persistent key seeds produce a reduced-strength AES keyCVE-2026-4936 · IBM PowerVM Hypervisor Platform KeyStore (PKS) and virtual TPM, FW950 / FW1060 / FW1110Medium
- OpenIPMI before 2.0.36: Where this bites an operator is in test and CI infrastructure rather than production nodesCVE-2024-42934 · OpenIPMI before 2.0.36Medium
- Dell SmartFabric OS10: command injection lets a high-privileged remote user run arbitrary OS commandsCVE-2026-35160 · Dell SmartFabric OS10 (switch NOS command handling)Medium
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.