CVE-2019-19195
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 · uneditedThe Bluetooth Low Energy implementation on Microchip Technology BluSDK Smart through 6.2 for ATSAMB11 devices does not properly restrict link-layer data length on reception, allowing attackers in radio range to cause a denial of service (crash) via a crafted packet.
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 · moderate confidenceThe BLE stack in Microchip BluSDK Smart through v6.2 for ATSAMB11 devices lacks proper input validation on incoming link-layer data length. An attacker within radio range can send a crafted BLE packet with oversized data that triggers a crash (denial of service) due to the missing bounds check.
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<= 6.2CVSS 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
- Adjacent
- Complexity
- Low
- Privileges
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- None
- Integrity
- None
- Availability
- High
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/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 checksWork through these to decide whether this CVE applies to you.
-
Identify the hardware platformInspect the device or firmware documentation to confirm it uses a Microchip ATSAMB11 microcontroller or module. Check PCB markings, bill of materials, or firmware build artifacts for 'ATSAMB11' or 'SAMB11' identifiers.Affected if The device is not based on ATSAMB11 hardware - this CVE only affects that specific chipset.
-
Determine the BluSDK Smart versionLocate the BluSDK Smart library or firmware version file. Check SDK release notes, firmware build metadata, or the libbluetooth.a / blu_sdk.a library version. Compare against v6.2.Affected if The installed BluSDK Smart version is 6.2 or earlier. Versions after 6.2 may contain the bounds check fix.
-
Verify BLE link-layer processing is activeCheck the BLE stack initialization code or runtime configuration. Confirm that HCI/Link Layer is enabled and processing incoming BLE data. Look for BLE_GAP_Adv_Start, hci_le_set_advertising_parameters, or similar BLE host controller interface calls in the firmware.Affected if BLE link-layer processing is disabled and no BLE advertising/scanning is active - the flaw requires the stack to accept incoming link-layer packets.
-
Assess BLE radio exposureEvaluate the physical deployment: is the device in a controlled-access area, public space, or outdoor environment where unauthorized attackers could be within BLE radio range (typically 10-100m line-of-sight)?Affected if The device is publicly accessible or in an area with untrusted nearby users - the vulnerability is exploitable by any attacker within radio range without authentication.
You are affected if you deploy an ATSAMB11-based device running BluSDK Smart version 6.2 or earlier with BLE link-layer processing enabled in an environment where untrusted individuals could be within BLE radio range.
Generated from the published advisory. Verify against your own configuration.
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 dataUpdate to a patched version of BluSDK if available; otherwise implement network-level controls to limit BLE radio exposure, as the vulnerability is exploitable by any nearby attacker.
- Consultation6.0 h
- Implementation16.0 h
- Testing12.0 h
- Review / QA8.0 h
An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $11,712.
Scan for this in your stack
Free · runs locallyCheck whether your project pulls in CVE-2019-19195 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.
References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.
Primary sourcesPractitioner notes
ContributedPeer-ranked notes from engineers who’ve handled CVE-2019-19195 in production — separate from our analysis above.
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
- The version that genuinely resolved it — not the one the vendor claimed
- A config change or rule that shut the vector down
- A gotcha in the upgrade path that cost you an afternoon
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.
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.
- 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