Talos Vulnerability Report

SUMMARY

A buffer overflow vulnerability exists in the CvManager_SBI functionality of Dell ControlVault3 5.14.3.0 and 5.15.10.14, A31. A specially crafted ControlVault API call can lead to a arbitrary code execution. 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 5.15.10.14, A31

PRODUCT URLS

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

CVSSv3 SCORE

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

CWE

CWE-120 - Buffer Copy without Checking Size of Input (‘Classic Buffer Overflow’)

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.

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. If no Application firmware is installed (or during the firmware upgrade process that erase the application firmware) the SBI (Secure Boot Image) can be interfaced with in the same fashion, but will only expose a limited number of commands that can be interacted with.

When a command blob is received from the USB stack, the firmware will read it into a global buffer (possibly called CV_SECURE_IO_COMMAND_BUF), then will verify a few parameters [0] (e.g. command size, type, …).

For reference, the ControlVault USB commands have a header as follow (source: debug symbols included in libfprint-2-tod-1-broadcom.so ):

struct td_cv_encap_command
{
  cv_transport_type transportType;
  uint32_t transportLen;
  cv_command_id commandID;
  cv_encap_flags flags;
  cv_version version;
  uint32_t hSession;
  cv_status returnStatus;
  uint8_t IV[16];
  uint32_t parameterBlobLen;
  uint32_t parameterBlob;
};

The verification function does the following:

// a1 is CV_SECURE_IO_COMMAND_BUF
int __fastcall cv_is_cmd_valid(int a1, unsigned int a2, int a3) {
        /* more checks */
  v5 = *(unsigned __int8 *)(a1 + 4) | (*(unsigned __int8 *)(a1 + 5) << 8) | (*(unsigned __int8 *)(a1 + 6) << 16) | (*(unsigned __int8 *)(a1 + 7) << 24);  // [0]
  if ( v5 > 0x10080 )
  {
    log_stuff("CV: command too long (%u)\n", v5);   
    return 0;
  }
  
 }

Upon success, the command will be passed to the CvManager_SBI function that acts as a command dispatcher. However, before processing the command, CvManager_SBI will copy the command from the CV_SECURE_IO_COMMAND_BUF into a different global buffer we call cv_cmd_buffer ([1]):

int cvManager_SBI()
{
 
        /* Variable definition and initialization */
        
  memcpy((int)cv_cmd_buffer, CV_SECURE_IO_COMMAND_BUF, *(int *)&CV_SECURE_IO_COMMAND_BUF[4]);  //[1]
  if ( *(unsigned __int16 *)&cv_cmd_buffer[8] != 68 && *(unsigned __int16 *)&cv_cmd_buffer[8] != 144 )
    log_stuff("%s: cid %x \n", "cvManager_SBI", *(unsigned __int16 *)&cv_cmd_buffer[8]);
  v16 = *(_WORD *)&cv_cmd_buffer[10];
  
      /* ... */
 }

The integer value stored at CV_SECURE_IO_COMMAND_BUF[4] is the transportLen size received over USB and it is the value used for the memcpy at [1]. It is also the value retrieved in v5 and checked at [0]. We can see at [0] that the maximum size allowed for the command blob is 0x10080 however the size of the cv_cmd_buffer is only 4096 bytes. As such, it is possible to send a command that will still be considered valid at [0] but will cause a buffer overflow at [1]. The cv_cmd_buffer is stored in global memory and adjacent to critical data structures such as the Secure Code Descriptor (SCD) containing the public key used to verify a firmware update. As such, it is possible to overflow the cv_cmd_buffer with attacker controlled data that can forge the SCD, overwriting the public key used to verify a firmware update, and thus forge an application firmware update that will be considered as valid.

TIMELINE

2025-05-09 - Vendor Disclosure
2025-06-13 - Vendor Patch Release
2025-11-17 - Public Release