Buffer Overflow in USB DFU requested length


USB DFU has a potential buffer overflow where the requested length (wLength) is not checked against the buffer size. This could be used by a malicious USB host to exploit the buffer overflow.

See NCC-ZEP-002




David Brown
March 3, 2020, 6:33 PM

CVE CVE-2020-10019

Jeremy Boone
March 11, 2020, 2:46 PM

The above PR seems to be associated with NCC finding #002, not #024. I’ve updated the description to include both.

David Brown
March 11, 2020, 4:36 PM

As I understand, the patch fixes both NCC-NCC-002, and NCC-NCC-024.

Jeremy Boone
March 11, 2020, 8:45 PM

So this is how I’m matching findings to PRs…


All of these 3 findings affect the USB Mass Storage driver (mass_storage.c) and appear to be fixed by a single PR:

  • NCC-024 / ZEPSEC-?? - Arbitrary Read And Limited Write In The USB Mass Storage Driver

  • NCC-025 / ZEPSEC-26 - Out-of-Bounds Write In The USB Mass Storage memoryWrite Handler With Unaligned Sizes

  • NCC-026 / ZEPSEC-33 - Integer Underflow In The USB Mass Storage Driver memoryWrite And memoryVerify Handlers


The following finding affects the USB DFU mode (usb_dfu.c) which is distinct from the mass storage driver issues above. It appears to be fixed by the following PR:

  • NCC-002 / ZEPSEC-25 - USB DFU Mode Can Overflow A Global Buffer In The DFU_UPLOAD Command


EDIT: So I think I’ve untangled my confusion now. My post above (saying that PR23190 was not associated with this finding) was incorrect. My confusion seems to have stemmed from:

  • There does not appear to be a Jira issue for the mass storage issue NCC-024. Although maybe this is not a big deal since a single PR fixed all mass storage findings (NCC-024, NCC-025 and NCC-026).

  • Comments in ZEPSEC-33 (a mass storage finding) which state that PR23190 fixed it, when it should actually say PR23240. PR23190 is USB DFU, not mass storage.

Sorry for introducing confusion. I’m trying to ensure I’m verifying fixes on my end, and got lost in my own head.


David Brown
March 12, 2020, 11:58 PM

The reason I combined them is because of the CVE numbering rules (the intent is for each ZEPSEC issues to correspond with a single CVE) only allow a single CVE number when there is a single fix, even if multiple things are fixed.


David Brown


David Brown



Authorized viewers

Jeremy Boone



Embargo Lift



Fix versions

Affects versions