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.
The above PR seems to be associated with NCC finding #002, not #024. I’ve updated the description to include both.
As I understand, the patch fixes both NCC-NCC-002, and NCC-NCC-024.
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.
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.