Talos Vulnerability Report

TALOS-2024-2127

Dell ControlVault3 cv_send_blockdata out-of-bounds read vulnerability

August 9, 2025
CVE Number

CVE-2025-24311

SUMMARY

An out-of-bounds read vulnerability exists in the cv_send_blockdata functionality of Dell ControlVault3 5.14.3.0. A specially crafted ControlVault API call can lead to an information leak. An attacker can issue an api call to trigger this vulnerability.

CONFIRMED VULNERABLE VERSIONS

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
Dell ControlVault3 Driver and Firmware prior to 5.15.10.14
Dell ControlVault3 Plus Driver and Firmware prior to 6.2.26.36

PRODUCT URLS

ControlVault3 - https://dell.com/ BCM5820X - https://www.broadcom.com/products/embedded-and-networking-processors/secure/bcm5820x

CVSSv3 SCORE

8.4 - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:H

CWE

CWE-20 - Improper Input Validation

DETAILS

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.

Context

On windows, any low privilege user can interface with the ControlVault3 hardware. In order to do so, a userland dll bcmbipdll.dll can be used to talk with the device driver cvusbdrv.sys which in turns talk over USB to the ARM firmware running on the BCM5820X chip implementing the secure context. First, a session needs to be created calling the cv_open function, which will return a pointer to a session object. This session object lives in a dedicated heap of ARM Firmawre

Vulnerability

Firmware side, the cv_send_blockdata functions appears to be incomplete / unimplemented and only compute an XOR checksum. It takes three parameters: a data pointer, a size and a value:

int __fastcall cv_send_blockdata(int size, unsigned __int8 *src, int expected_value)
{
  if ( rolling_xor(size, src) == expected_value )
return 0;
  else
return 0x47;
}

Upon invokation, size bytes will be xored in the rolling xor from the src pointer, and then compared with the expected_value provided. Using the cv_send_blockdata function exported by bcmbipdll.dll, the size field is checked computer side to be sure it is within allowed range but if the function is directly invoked via its command_code (0x55) it is possible to provide an arbitrary size value leading to an out-of-bound read past the end of the data that was provied. It then becomes possible to use this function as an xor-oracle (akin to padding oracle attacks to crypto systems) where one can try the whole range of expected values until the proper value is found, thus revealing one byte of data. This attack is successful as long as the data read out of bound remains the same in between function calls.

Impact

Due to the constraint mentioned above, only a limited amount of data can be leaked. From our testing it appears that around 0x466c bytes can be leaked, which consist of the CV_COMMAND_BUF, CV_HEAP, CV_PERSISTED_FP, and other global data structures. The CV_COMMAND_BUF is not cleared between function invokation, and thus can leak sensitive information from past API calls. The CV_HEAP structures contains object that were created dynmaically and user sessions, both potentially containing sensitive information. Further, this OOB-read can also be used as a denial of service if the provided size field is made very large, leading to the rolling xor trying to read data in an unmapped memory region.

VENDOR RESPONSE

Vendor advisory: https://www.dell.com/support/kbdoc/en-us/000276106/dsa-2025-053

TIMELINE

2024-12-18 - Vendor Disclosure
2025-06-13 - Vendor Patch Release
2025-08-09 - Public Release

Credit

Discovered by Philippe Laulheret of Cisco Talos.