CVE-2025-31361
A privilege escalation vulnerability exists in the ControlVault WBDI Driver WBIO_USH_ADD_RECORD functionality of Dell ControlVault3 5.14.3.0. A specially crafted WinBioControlUnit call can lead to privilege escalation. An attacker can issue an api call to trigger this vulnerability.
The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.
Broadcom BCM5820X
Dell ControlVault3 5.14.3.0
ControlVault3 - https://dell.com/ BCM5820X - https://www.broadcom.com/products/embedded-and-networking-processors/secure/bcm5820x
8.7 - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L
CWE-908 - Use of Uninitialized Resource
Dell ControlVault is a hardware based solution that can securely store passwords, biometric templates and security codes. It can interface with smart cards, Near-field Communication (NFC) devices and fingerprint readers. The hardware solution is based on the Broadcom BCM5820X chip series.
Control Vault WBDI Driver is Broadcom’s implementation of the Windows Biometric Driver Interface (WBDI) leveraging the Control Vault hardware to provide biometrics features using Windows APIs. The relevant features are implemented inside three DLLs (BrcmEngineAdapter.dll, BrcmSensorAdapter.dll, BrcmStorageAdapter.dll). The vulnerabilities in this reports are all found inside Broadcom’s implementation of the Storage Adapter. Biometrics drivers are instantiated by the WinBio Service running under svchost as SYSTEM.
When implementing the various WinBio interfaces, an Adapter can provide a mechanism akin to a DeviceIoControl by implementing the ControlUnit and/or ControlUnitPrivileged functions. Any unprivilege user can access the ControlUnit function by first opening a WinBio session (WinBioOpenSession) locking the relevant BiometricUnit (WinBioLockUnit) and finally issuing the control command (WinBioControlUnit). These control commands are vendor-defined and thus will vary between vendors/models. One can also choose to limit access to the more critical APIs by implementing sensitive features under the ControlUnitPrivileged function instead .
The Broadcom Storage Adapter implements multiple unprivileged operations inside the ControlUnit function including one called WBIO_USH_ADD_RECORD. This functionality is responsible for adding the caller’s provided data into the Storage’s database to associate a template handle (used during fingerprint matching) with a user’s identity in the form of a WINBIO_IDENTITY object. Adding a record in the Storage’s database should be a privileged operation as it can lead to allowing a user to authenticate under a different identity via their fingerprint. As such, the execution of this operation is gated with a 0x20-byte challenge:
if ( control_code_minus_3 == 1 )
{
log_stuff((int)L"StorageAdapterControlUnit() WBIO_USH_ADD_RECORD\n");
if ( *(_QWORD *)(SendBuffer + 84) == *(_QWORD *)&StorageContext->Challenge.field_0 //[0]
&& *(_QWORD *)(SendBuffer + 92) == *((_QWORD *)&StorageContext->Challenge.field_0 + 1)
&& *((_DWORD *)SendBuffer + 25) == StorageContext->Challenge.field_10 )
{
if ( WBFUSH_ExistsCVObject(*((_DWORD *)SendBuffer + 20), &objType) ) //[1]
{
if ( objType == CV_TYPE_FINGERPRINT )
{
v32.Subfactor = SendBuffer[76];
v32.IndexVector = 0i64;
v32.IndexElementCount = 0i64;
v32.PayloadBlob = 0i64;
v32.PayloadBlobSize = 0i64;
v32.Indentity = (WINBIO_IDENTITY *)SendBuffer; //[2]
v32.TemplateBlob = (__int64)(SendBuffer + 80);// templateBlob_cv_handle
v32.TemplateBlobSize = 4i64;
if ( StorageContext->BrcmStorageAdapterAddRecord(Pipeline, &v32) >= 0 ) //[3]
{
*ReceiveDataSize_ = 0i64;
status = 0;
*OperationStatus_ = 0;
}
else
{
log_stuff((int)L"StorageAdapterControlUnit. BrcmAddRecord\n");
*OperationStatus_ = 9;
status = 0;
}
}
else
{
log_stuff((int)L"StorageAdapterControlUnit. Not a FP template\n");
status = 0;
*OperationStatus_ = 10;
}
}
else
{
log_stuff((int)L"StorageAdapterControlUnit. WBFUSH_ExistsCVObject Failed\n");
status = 0;
*OperationStatus_ = 8;
}
}
else
{
log_stuff((int)L"StorageAdapterControlUnit. WBIO_USH_ADD_RECORD authorization Failed\n");
status = 0;
*OperationStatus_ = 7;
}
}
We can see that at [0] the data provided to the API call is checked against the StorageContext->Challenge object and in case of mismatch the function will fail. However upon success, the data provided in the API call will be stored inside the adapter’s database ([2], [3]) assuming the provided template handle already exists in the Control Vault device ([1]). This requirement only means that a fingerprint must have already been recorded via other APIs.
The vulnerability here lays in the fact that by default the StorageContext->Challenge object is uninitialized and will default to an array of null-bytes (this is because the StorageContext object is allocated with a call to HeapAlloc with the HEAP_ZERO_MEMORY flag). For the challenge to be initialized, it would be required to call WBIO_USH_CREATE_CHALLENGE. However, it appears that no component calls this function, and as such the challenge remains un-initialized.
If two users on the same machine are both using Windows Hello with fingerprint login, a consequence of this attack is to enable a user to enroll an new fingerpint on the ControlVault device and then register it under the other user using the WBIO_USH_ADD_RECORD command. Certain mechanisms are in place inside the WinBio framwork to prevent this attack (verifying the hash of the template used and authenticating the stack using a “payload object” provided by the WinBio Framework during the fingerprint enrollment). That being said, these mitigations are configuration and hardware dependent; ControlVault supports multiple variants of fingerprint readers, some compatible with Windows Enhanced Secure Sign-in (ESS) while some are not. It seems that ESS needs to be specifically enabled in order to have those mitigations enabled.
2025-04-22 - Vendor Disclosure
2025-06-13 - Vendor Patch Release
2025-11-17 - Public Release
Discovered by Philippe Laulheret of Cisco Talos.