Database/Firmware, BMC & network fabric

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
Related entries
- Juniper Junos OS kernel: Improper isolation in the Junos kernel lets a local attacker with shell access injectCVE-2025-21590 · Juniper Junos OS kernelMedium
- Lenovo XClarity Controller (LDAP mode): Read-only authentication bypass when XCC is in LDAP-only authentication modeCVE-2021-3956 · Lenovo XClarity Controller (LDAP mode)Medium
- tpm2-tss (FAPI quote verification): The JSON quote info returned by Fapi_Quote accepts an arbitrary TPM2_GENERATEDCVE-2024-29040 · tpm2-tss (FAPI quote verification)Medium
- Lenovo XClarity Controller (XCC) - audit log: When an account username is exactly 16 characters, XCC writes the IPMICVE-2024-8059 · Lenovo XClarity Controller (XCC) - audit logMedium
- Intel Xeon 6 with TDX: coarse access control in a processor subsystem exposes data to an authenticated local userCVE-2025-31938 · Intel Xeon 6 Scalable processors with Intel TDX (subsystem access control)Medium
- Arista DANZ Monitoring Fabric: debug API exposes config database contents including user password hashesCVE-2025-54548 · Arista DANZ Monitoring Fabric (debug API exposing the config database)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.