CVE-2023-6249 is a High severity (CVSS 8.0) signed to unsigned conversion bug in the ESP32 inter processor messaging driver of the Zephyr RTOS, affecting version 3.5 and earlier. A negative size can slip past a length check and cause a buffer overflow. The advisory lists no patched release.
What's affected
The Zephyr project published GitHub advisory GHSA-32f5-3p9h-2rqc on 18 February 2024, with severity High.
- Affected: zephyr 3.5 and earlier (stated as 3.5 or lower in the advisory).
- Patched versions: the advisory lists none. Check the Zephyr repository and release notes for a fix landed after the advisory.
- Component: the
esp32_ipm_sendfunction indrivers/ipm/ipm_esp32.c. - Severity: NVD scores it 8.0 High, with the weakness classified as CWE-704, incorrect type conversion or cast.
This only matters if your firmware is built for an ESP32 target and uses the IPM driver to pass messages between its two cores. Boards and applications that do not enable that driver are not exposed through this code.
How to check if you're exposed
Zephyr is source code that you build into firmware, so the check happens in your build.
- Find the Zephyr version your project uses. For a west workspace, look at the
VERSIONfile in the Zephyr tree, or runwest list zephyr. - Check whether your target is an ESP32 family board.
- Search your configuration for the IPM driver. In Kconfig terms, look for the option that enables IPM and the ESP32 implementation in your final
.config. - Search your application code for calls to
ipm_sendthat pass a size computed at run time.
west list zephyr
grep -i ipm build/zephyr/.config
If you ship firmware to customers, add the result to your product's software bill of materials so you can answer questions about it later.
What to do now
- Confirm whether any product uses an ESP32 target with the IPM driver enabled. If not, document that and close the item.
- Track the Zephyr repository for a fix to esp32_ipm_send and move to the first release that includes it.
- Until then, make sure every caller of ipm_send passes a size that cannot be negative, and validate it before the call.
- Review your own drivers for the same pattern: a signed length compared against a limit, then used as an unsigned length.
- Plan a firmware update path for deployed devices, because embedded fixes only help once they are flashed.
Why it matters
The advisory explains the mechanism in two sentences. The function takes the size as a signed integer and checks it against the size of shared memory. A negative value passes that check because it is smaller than the limit. It is then handed to a memory copy routine that treats the length as unsigned, so the negative number becomes a very large copy.
This is a classic integer handling bug and a good reminder that bounds checks must reject both ends of a range. It is also a reminder that embedded software moves slowly. Even when a fix exists, devices stay vulnerable until someone flashes them. The kev flag is false, and the advisory does not describe exploitation.
Quick check
Is every Zephyr user affected?
No. The bug is in the ESP32 IPM driver, so it matters for ESP32 builds that use inter processor messaging.
Is there a fixed release?
The advisory lists no patched version. Check the Zephyr repository for a later fix.
Sources
Last reviewed: 19 October 2026.
