Talos Vulnerability Report

SUMMARY

An arbitrary free vulnerability exists in the cv_close functionality of Dell ControlVault3 5.14.3.0. A specially crafted ControlVault API call can lead to an arbitrary free. An attacker can forge a fake session 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.2 - CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H

CWE

CWE-763 - Release of Invalid Pointer or Reference

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

When calling cv_close, a pointer to a session is expected as the only argument to the function. On the firmware side, when the cv_close function is triggered, it does the following:

    int __fastcall cv_close(cv_session *a1)
    {
      int v2; // r4
      cv_session *CV_HEAP; // r3
      cv_volatile_obj_dir *v4; // r0
      unsigned __int8 *v5; // r3
      unsigned __int8 *v6; // r0
      void *v7; // r2

      if ( !cv_validate_sess(a1) )  // [1]
      {
        v2 = a1->flags & 0x40;
        if ( (a1->flags & 0x40) == 0 )
        {
             //snipped
        }
        CV_HEAP = globals->CV_HEAP;
        if ( a1 < CV_HEAP || a1 >= CV_HEAP_END )
        {
          log_stuff("cv_close: invalid session handle 0x%x\n", a1);
        }
        else
        {
          memset(a1, 0, 4);
          cv_free(a1, 0x64);  // [2]
       }
    }
  return 0;
}

The code verifies the session is valid at [1] and if so, free the pointer at [2]. However, the validation of a session is insufficient:

int __fastcall cv_validate_sess(cv_session *a1)
{
  global_stuff *v2; // r5
  unsigned int CV_HEAP; // r3
  int result; // r0
  int v5; // r1
  CV_VOLATILE_DATA *CV_VOLATILE_DATA; // r2
  bool v7; // zf
  int v8; // r3

  v2 = globals;
  CV_HEAP = globals->CV_HEAP;
  if ( a1 < CV_HEAP )           //[3]
    return CV_INVALID_HANDLE;
  if ( a1 >= CV_HEAP + 3072 )   //[3b]
    return CV_INVALID_HANDLE;
  result = memcmp(a1, "SeSs", 4);   // [4]
  if ( result )
    return CV_INVALID_HANDLE;

    /** snipped **/ 

  return result;
}

The code verifies that the pointer provided is located within the expected range (at [3] and [3b])], and that the magic bytes "SeSs" (at [4]) are present as the first 4 bytes of the begining of the data provided.

This verification is insufficient as it is possible to allocate other objects on this heap (using cv_create_object) and place the appropriate data (fake heap metadata + SeSS ) to forge a fake session that can be arbitrarily freed assuming its address is known. Knowing the rough memory range of the CV_HEAP, it is possible to use any APIs that takes a session as a prameter and that behaves differently whether the session is valid or not to create an oracle that will leak the address of the forged session. One such function is cv_get_random(addr, 0x200) that will either return error 0x34 (size too big) if addr points to a valid session or error 6 (invalid session) if the addr does not point to a valid session.

Consequences

As it is possible to forge an object that looks like a valid session, a malicious user can forge a session by creating an object, and then free this fake session while the system will retain references to the object. This enables various forms of heap corruption (user-after-free, corruption of the heap metadata, …) potentially leading to arbitrary code execution in the context of the ARM Firmware. An example of such attack is to re-use the wrongly freed memory within the object to allocate another object or session, thus overlapping the two objects and enabling the modifcation of the latter by using regular APIs (e.g. cv_set_object) to modify the content of the first object.

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