dbcve.org
Cyw20735 FirmwareOperating system · Cypress

CVE-2019-18614

HIGH · 7.8 CVSS v3.1 Published 2020-06-16
Mitigation only
No fix yet — a mitigation exists. There is no fixed release. A documented workaround reduces exposure in the meantime.
See remediation →
80/100
Remediation priority · High
Zero-click

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
On the Cypress CYW20735 evaluation board, any data that exceeds 384 bytes is copied and causes an overflow. This is because the maximum BLOC buffer size for sending and receiving data is set to 384 bytes, but everything else is still configured to the usual size of 1092 (which was used for everything in the previous CYW20719 and later CYW20819 evaluation board). To trigger the overflow, an attacker can either send packets over the air or as unprivileged local user. Over the air, the minimal PoC is sending "l2ping -s 600" to the target address prior to any pairing. Locally, the buffer overflow is immediately triggered by opening an ACL or SCO connection to a headset. This occurs because, in WICED Studio 6.2 and 6.4, BT_ACL_HOST_TO_DEVICE_DEFAULT_SIZE and BT_ACL_DEVICE_TO_HOST_DEFAULT_SIZE are set to 384.

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · high confidence

A buffer overflow vulnerability exists in the Cypress CYW20735 evaluation board where the BLOC buffer size is set to 384 bytes while ACL buffer sizes remain configured at 1092 bytes. This mismatch allows data exceeding 384 bytes to overflow the BLOC buffer when sending packets over the air (e.g., via l2ping -s 600) or when opening ACL/SCO connections locally, enabling potential code execution or denial of service.

MitigationUpdate WICED Studio to a version where BT_ACL_HOST_TO_DEVICE_DEFAULT_SIZE and BT_ACL_DEVICE_TO_HOST_DEFAULT_SIZE are consistently set to match the BLOC buffer size (1092 bytes), or apply the vendor patch that corrects the buffer size configuration.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.

NVD · CPE data
Cyw20735 FirmwareOperating system
Affected:all versions

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Local
Complexity
Low
Privileges
Low
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

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

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Identify CYW20735 hardware
    Check system documentation, device firmware metadata, or Bluetooth controller identification (e.g., hciinfo, hciconfig hci0, or vendor-specific tools) to confirm the Cypress CYW20735 chipset is in use
    Affected if The system uses a Cypress CYW20735 evaluation board or module
  2. Determine firmware version
    Query the Bluetooth controller firmware version using commands such as hcitool -i hci0 ver, btmgmt -i hci0 info, or vendor-provided tools; compare against the affected product listing
    Affected if Firmware is from Cypress CYW20735 (all versions listed as affected)
  3. Inspect buffer size configuration
    Examine firmware configuration files or memory maps for BT_ACL_HOST_TO_DEVICE_DEFAULT_SIZE and BT_ACL_DEVICE_TO_HOST_DEFAULT_SIZE values; verify if ACL buffers are set to 1092 bytes while BLOC buffer remains at 384 bytes
    Affected if ACL buffer sizes (1092 bytes) exceed BLOC buffer size (384 bytes), creating the mismatch condition
  4. Test for overflow with oversized packet
    Use l2ping -s 600 <target_mac> or similar tool to send a 600-byte packet to the CYW20735 device and observe for crash, hang, or unexpected behavior
    Affected if Sending packets larger than 384 bytes triggers a buffer overflow or causes the device to become unresponsive
  5. Verify ACL/SCO connection handling
    Open ACL or SCO connections locally to the device using tools like btmgmt or rfcomm connect and monitor for abnormal behavior or crash
    Affected if Opening ACL/SCO connections locally causes denial of service or code execution symptoms

If the system uses Cypress CYW20735 firmware with ACL buffers configured at 1092 bytes while BLOC buffers remain at 384 bytes, it is vulnerable to the buffer overflow; confirm by testing with l2ping -s 600 or oversized ACL packets.

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

From vendor data
Mitigation available No clean upgrade yet — mitigate in the meantime
Mitigation

Update WICED Studio to a version where BT_ACL_HOST_TO_DEVICE_DEFAULT_SIZE and BT_ACL_DEVICE_TO_HOST_DEFAULT_SIZE are consistently set to match the BLOC buffer size (1092 bytes), or apply the vendor patch that corrects the buffer size configuration.

Fix this in Cyw20735 Firmware Scoped from the published advisory
  • Consultation4.0 h
  • Implementation8.0 h
  • Testing8.0 h
  • Review / QA4.0 h
24.0 hours of engineering $4,160
Get help mitigating

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $6,656.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2019-18614 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

Get it on GitHub Scan in the browser

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2019-18614 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data