SUMMARY

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

When a command blob is received from the USB stack, the firmware will read it into a global buffer 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:

  int __fastcall cvIsCmdValid(int a1, unsigned int recieved_size, int a3)
   {
      unsigned int command_size_from_packet; // r1

      if ( recieved_size == 12 )
      {
        if ( *(_DWORD *)a1 == 2 )
        {
          if ( *(_DWORD *)(a1 + 8) == 37 )
          {
            log_stuff("CV: Bad host-storage packet detected\n");
            return 0;
          }
        }
        else if ( *(_DWORD *)a1 == 4 && *(_DWORD *)(a1 + 8) == 42 )
        {
          log_stuff("CV: Bad host-control packet detected\n");
          return 0;
        }
      }
      command_size_from_packet = *(unsigned __int8 *)(a1 + 4) | (*(unsigned __int8 *)(a1 + 5) << 8) | (*(unsigned __int8 *)(a1 + 6) << 16) | (*(unsigned __int8 *)(a1 + 7) << 24);
      if ( command_size_from_packet > 0x10080 )  // [0]
      {
        log_stuff("CV: command too long (%u)\n", command_size_from_packet);
        return 0;
      }
     
         /* more checks */
       return 1;
   }

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

 void CvManager()
{
   /* variable definition and initialization ... */ 

   cmd_ = (cv_encap_command *)*get_volatile_mem_ptr_ptr();// get the CV_SECURE_IO_COMMAND_BUF
  memcpy(
    (unsigned __int8 *)globals->CV_COMMAND_BUF,
    (unsigned __int8 *)cmd_,
    LOBYTE(cmd_->transportLen) | (BYTE1(cmd_->transportLen) << 8) | (BYTE2(cmd_->transportLen) << 16) | (HIBYTE(cmd_->transportLen) << 24));   // [1]
  CV_COMMAND_BUF = (cv_encap_command *)globals->CV_COMMAND_BUF;
  
     /* ... */
 }

The cmd_->transportLen value was part of the encapsulated command received over USB (and thus attacker controlled) and it is used for the memcpy at [1]. It is the same value that was 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_COMMAND_BUF is stored in global memory and adjacent to critical data structures such as the CV_HEAP used to hold Session objects and various in-memory cv_objects. Through this buffer overflow, it is possible to corrupt various data structures including heap-metadata, potentially leading to arbitrary read/write and likely code execution as well.

TIMELINE

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