{"id":"CVE-2026-12051","aliases":["EUVD-2026-55939","GHSA-vhvq-q6rw-jvm4"],"status":"published","title":"NULL pointer dereference in USB DFU device_next download handler (handle_download)","description":"The USB DFU class implementation in Zephyr's new (experimental) device_next USB device stack contains a NULL pointer dereference in handle_download() (subsys/usb/device_next/class/usbd_dfu.c). The handler computes MIN(setup-\u003ewLength, buf-\u003elen) and passes buf-\u003edata to the image write callback without checking that the buf net_buf pointer is non-NULL.\n\nThe handler is reached over the USB control endpoint, driven by the USB host. For a DFU_DNLOAD (download) request with no Data OUT stage — notably the zero-length terminating download that the DFU protocol uses to end a firmware transfer — the USB core invokes the class handler with a NULL buffer. After the device has been advanced to the DFU_DNLOAD_IDLE state (by sending one valid download block and a GET_STATUS), a zero-length DFU_DNLOAD reaches handle_download() with buf == NULL, dereferencing it.\n\nThe result is a NULL+offset read that triggers a fatal CPU fault, i.e. a denial of service (device crash/reset). The attacker is whatever controls the USB host the device is attached to; DFU download support must be enabled with a registered image. There is no memory corruption or information disclosure — impact is limited to availability. The fix adds an explicit if (buf != NULL) guard so the callback receives a zero-length, NULL-data transfer instead of crashing.","severity":{"version":"3.1","score":4.6,"vector":"CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-12","score":0.0023,"percentile":0.13997,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":false},"cwes":["CWE-476"],"published":"2026-08-11T05:31:19Z","modified":"2026-10-28T11:03:06Z","products":[{"vendor":"zephyrproject","product":"zephyr"},{"vendor":"zephyrproject-rtos","product":"zephyr"}],"references":[{"url":"https://github.com/zephyrproject-rtos/zephyr/commit/552ca371257597b71490482d5cc597157ea60f12","tags":["patch","fix"]},{"url":"https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-vhvq-q6rw-jvm4","tags":["advisory"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/12xxx/CVE-2026-12051.json","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-12051","tags":["advisory"]},{"url":"https://github.com/zephyrproject-rtos/zephyr","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-12051","title":"NULL pointer dereference in USB DFU device_next download handler (handle_download)","description":"The USB DFU class implementation in Zephyr's new (experimental) device_next USB device stack contains a NULL pointer dereference in handle_download() (subsys/usb/device_next/class/usbd_dfu.c). The handler computes MIN(setup-\u003ewLength, buf-\u003elen) and passes buf-\u003edata to the image write callback without checking that the buf net_buf pointer is non-NULL.\n\nThe handler is reached over the USB control endpoint, driven by the USB host. For a DFU_DNLOAD (download) request with no Data OUT stage — notably the zero-length terminating download that the DFU protocol uses to end a firmware transfer — the USB core invokes the class handler with a NULL buffer. After the device has been advanced to the DFU_DNLOAD_IDLE state (by sending one valid download block and a GET_STATUS), a zero-length DFU_DNLOAD reaches handle_download() with buf == NULL, dereferencing it.\n\nThe result is a NULL+offset read that triggers a fatal CPU fault, i.e. a denial of service (device crash/reset). The attacker is whatever controls the USB host the device is attached to; DFU download support must be enabled with a registered image. There is no memory corruption or information disclosure — impact is limited to availability. The fix adds an explicit if (buf != NULL) guard so the callback receives a zero-length, NULL-data transfer instead of crashing.","status":"published","published":"2026-08-11T05:31:19.009Z","modified":"2026-08-31T23:13:23.141Z","cvss":[{"version":"3.1","score":4.6,"vector":"CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"medium","assessor":"cna"}],"cwes":["CWE-476"],"updated_at":"2026-11-02T14:19:48.461833Z"}],"euvd":[{"id":"EUVD-2026-55939","description":"The USB DFU class implementation in Zephyr's new (experimental) device_next USB device stack contains a NULL pointer dereference in handle_download() (subsys/usb/device_next/class/usbd_dfu.c). The handler computes MIN(setup-\u003ewLength, buf-\u003elen) and passes buf-\u003edata to the image write callback without checking that the buf net_buf pointer is non-NULL.\n\nThe handler is reached over the USB control endpoint, driven by the USB host. For a DFU_DNLOAD (download) request with no Data OUT stage — notably the zero-length terminating download that the DFU protocol uses to end a firmware transfer — the USB core invokes the class handler with a NULL buffer. After the device has been advanced to the DFU_DNLOAD_IDLE state (by sending one valid download block and a GET_STATUS), a zero-length DFU_DNLOAD reaches handle_download() with buf == NULL, dereferencing it.\n\nThe result is a NULL+offset read that triggers a fatal CPU fault, i.e. a denial of service (device crash/reset). The attacker is whatever controls the USB host the device is attached to; DFU download support must be enabled with a registered image. There is no memory corruption or information disclosure — impact is limited to availability. The fix adds an explicit if (buf != NULL) guard so the callback receives a zero-length, NULL-data transfer instead of crashing.","status":"published","published":"2026-08-11T05:31:19Z","modified":"2026-08-31T23:13:23Z","cvss":[{"version":"3.1","score":4.6,"vector":"CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"medium"}],"updated_at":"2026-11-02T18:01:19.818565Z"}],"nvd":[{"id":"CVE-2026-12051","description":"The USB DFU class implementation in Zephyr's new (experimental) device_next USB device stack contains a NULL pointer dereference in handle_download() (subsys/usb/device_next/class/usbd_dfu.c). The handler computes MIN(setup-\u003ewLength, buf-\u003elen) and passes buf-\u003edata to the image write callback without checking that the buf net_buf pointer is non-NULL.\n\nThe handler is reached over the USB control endpoint, driven by the USB host. For a DFU_DNLOAD (download) request with no Data OUT stage — notably the zero-length terminating download that the DFU protocol uses to end a firmware transfer — the USB core invokes the class handler with a NULL buffer. After the device has been advanced to the DFU_DNLOAD_IDLE state (by sending one valid download block and a GET_STATUS), a zero-length DFU_DNLOAD reaches handle_download() with buf == NULL, dereferencing it.\n\nThe result is a NULL+offset read that triggers a fatal CPU fault, i.e. a denial of service (device crash/reset). The attacker is whatever controls the USB host the device is attached to; DFU download support must be enabled with a registered image. There is no memory corruption or information disclosure — impact is limited to availability. The fix adds an explicit if (buf != NULL) guard so the callback receives a zero-length, NULL-data transfer instead of crashing.","status":"published","published":"2026-08-11T06:17:12.62Z","modified":"2026-10-23T19:10:00.167Z","cvss":[{"version":"3.1","score":4.6,"vector":"CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"medium","assessor":"secondary"}],"cwes":["CWE-476"],"updated_at":"2026-11-02T14:12:36.102748Z"}],"osv":[{"id":"CVE-2026-12051","title":"NULL pointer dereference in USB DFU device_next download handler (handle_download)","description":"The USB DFU class implementation in Zephyr's new (experimental) device_next USB device stack contains a NULL pointer dereference in handle_download() (subsys/usb/device_next/class/usbd_dfu.c). The handler computes MIN(setup-\u003ewLength, buf-\u003elen) and passes buf-\u003edata to the image write callback without checking that the buf net_buf pointer is non-NULL.\n\nThe handler is reached over the USB control endpoint, driven by the USB host. For a DFU_DNLOAD (download) request with no Data OUT stage — notably the zero-length terminating download that the DFU protocol uses to end a firmware transfer — the USB core invokes the class handler with a NULL buffer. After the device has been advanced to the DFU_DNLOAD_IDLE state (by sending one valid download block and a GET_STATUS), a zero-length DFU_DNLOAD reaches handle_download() with buf == NULL, dereferencing it.\n\nThe result is a NULL+offset read that triggers a fatal CPU fault, i.e. a denial of service (device crash/reset). The attacker is whatever controls the USB host the device is attached to; DFU download support must be enabled with a registered image. There is no memory corruption or information disclosure — impact is limited to availability. The fix adds an explicit if (buf != NULL) guard so the callback receives a zero-length, NULL-data transfer instead of crashing.","status":"published","published":"2026-08-11T05:31:19.009Z","modified":"2026-10-28T11:03:06.444354341Z","cvss":[{"version":"3.1","score":4.6,"vector":"CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"medium"}],"cwes":["CWE-476"],"updated_at":"2026-11-02T15:44:57.354194Z"}]}}