In subsys/debug/coredump/coredump_shell.c, print_coredump_hdr() used the 16-bit tgt_code field of a stored Zephyr coredump header directly as an index into coredump_target_code2str[], a fixed 7-element array of string pointers, with no bounds check.
A stored coredump whose tgt_code is >= 7 causes an out-of-bounds read of a char* up to ~64K entries past the array; that value is passed as the %s argument to shell_print, which dereferences and walks it as a string. The result is either disclosure of device memory contents to the shell user or a crash when the out-of-bounds pointer is unmapped.
The defect is reached via the coredump print shell command (cmd_coredump_print_stored_dump -> pretty_print_coredump -> parse_and_print_coredump -> print_coredump_hdr). The tgt_code field is device-generated and in-range during normal crash handling, so triggering requires local shell access plus the ability to stage or corrupt the stored coredump in the flash/in-memory backend.
Introduced in v4.2.0 (commit 13abd7f) and present through v4.4.0; fixed by clamping out-of-range codes to the 'unknown' (index 0) entry.
Affected components
Affected versions
v4.2.0, v4.2.1, v4.2.2, v4.3.0, v4.4.0
Fix
Fixed (merged) in a922632
Projected fixed version: 4.5.0 (the fix is merged on main but not yet released; this forecast should be confirmed against the actual release).
Introduced by: 13abd7f ("coredump: Generalize the shell module", v4.2.0)
Evidence
- subsys/debug/coredump/coredump_shell.c:44-52 — coredump_target_code2str has exactly 7 entries
- subsys/debug/coredump/coredump_shell.c (pre-fix, a922632^:185-211) — tgt_code used directly as array index with no bounds check, result passed to shell_print %s
- include/zephyr/debug/coredump.h:179 — tgt_code is a 16-bit field of __packed coredump_hdr_t, so index can reach 65535
- subsys/debug/coredump/coredump_shell.c:202-210 — post-fix clamp: index >= ARRAY_SIZE -> 0, closing the OOB read
- subsys/debug/coredump/coredump_shell.c:528-567 — reach: cmd_coredump_print_stored_dump -> pretty_print_coredump -> parse_and_print_coredump -> print_coredump_hdr (shell-gated)
- subsys/debug/coredump/coredump_core.c:83 — header is normally written by the device with a valid arch tgt_code (in-range under normal use)
- git tag --contains 13abd7f — vulnerable code shipped in v4.2.0..v4.4.0
Patches
For more information
If you have any questions or comments about this advisory:
embargo: 2026-07-28
In
subsys/debug/coredump/coredump_shell.c,print_coredump_hdr()used the 16-bittgt_codefield of a stored Zephyr coredump header directly as an index intocoredump_target_code2str[], a fixed 7-element array of string pointers, with no bounds check.A stored coredump whose
tgt_codeis >= 7 causes an out-of-bounds read of achar*up to ~64K entries past the array; that value is passed as the%sargument toshell_print, which dereferences and walks it as a string. The result is either disclosure of device memory contents to the shell user or a crash when the out-of-bounds pointer is unmapped.The defect is reached via the
coredump printshell command (cmd_coredump_print_stored_dump->pretty_print_coredump->parse_and_print_coredump->print_coredump_hdr). Thetgt_codefield is device-generated and in-range during normal crash handling, so triggering requires local shell access plus the ability to stage or corrupt the stored coredump in the flash/in-memory backend.Introduced in v4.2.0 (commit 13abd7f) and present through v4.4.0; fixed by clamping out-of-range codes to the 'unknown' (index 0) entry.
Affected components
subsys/debug/coredumpAffected versions
v4.2.0, v4.2.1, v4.2.2, v4.3.0, v4.4.0
Fix
Fixed (merged) in a922632
Projected fixed version: 4.5.0 (the fix is merged on
mainbut not yet released; this forecast should be confirmed against the actual release).Introduced by: 13abd7f ("coredump: Generalize the shell module", v4.2.0)
Evidence
Patches
mainv4.4-branchv4.3-branchFor more information
If you have any questions or comments about this advisory:
embargo: 2026-07-28