Buffer Overflow in USB DFU requested length

Description

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

Environment

None

Activity

Show:
David Brown
March 3, 2020, 6:33 PM

CVE CVE-2020-10019

Jeremy Boone
March 11, 2020, 2:46 PM
Edited

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
Edited

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:
https://github.com/zephyrproject-rtos/zephyr/pull/23240

  • 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:
https://github.com/zephyrproject-rtos/zephyr/pull/23190/files

  • 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.

Assignee

David Brown

Reporter

David Brown

Labels

None

Authorized viewers

Jeremy Boone

CVE

CVE-2020-10019

Embargo Lift

2020/05/01

Components

Fix versions

Affects versions

Priority

High
Configure