tests: drivers: reset: mmio: keep the fake registers out of kernel RAM - #116545
Merged
Conversation
nashif
added
the
Hotfix
zephyrbot
added
area: Reset
area: Tests
nashif
force-pushed
the
topic/hotfix/reset_crash
branch
from
August 18, 2026 00:36
38d9ce2 to
b140b73
Compare
The qemu_cortex_m3 overlay placed the fake reset-mmio registers at 0x20000004/0x20000008, inside the SRAM the kernel links into. The words they occupy are owned by whatever .data the linker places at the start of RAM, so every write through the reset driver corrupts live kernel state, and the test only ever passed by layout luck. A recent timer-core change added an 8-byte .data variable that landed at 0x20000000, which pushed libc's _char_out console output function pointer to exactly 0x20000008: the active-low test case then wrote its register patterns over the pointer, console output jumped through the corrupted value into a HardFault, the fault handler's own print re-took the fault, and QEMU stopped with "Lockup: can't escalate 3 to HardFault". Any future .data layout change could break this test the same way. Shrink the kernel's view of the 64 KiB SRAM by one KiB in the overlay and move the fake registers into the carved-out tail, so no linker layout can ever place kernel data under them. Assisted by Claude (claude-opus-4-8). Signed-off-by: Anas Nashif <anas.nashif@intel.com>
nashif
force-pushed
the
topic/hotfix/reset_crash
branch
from
August 18, 2026 00:36
b140b73 to
9b66b51
Compare
henrikbrixandersen
approved these changes
Aug 18, 2026
jhedberg
approved these changes
Aug 18, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The qemu_cortex_m3 overlay placed the fake reset-mmio registers at
0x20000004/0x20000008, inside the SRAM the kernel links into. The
words they occupy are owned by whatever .data the linker places at
the start of RAM, so every write through the reset driver corrupts
live kernel state, and the test only ever passed by layout luck.
A recent timer-core change added an 8-byte .data variable that landed
at 0x20000000, which pushed libc's _char_out console output function
pointer to exactly 0x20000008: the active-low test case then wrote
its register patterns over the pointer, console output jumped through
the corrupted value into a HardFault, the fault handler's own print
re-took the fault, and QEMU stopped with "Lockup: can't escalate 3 to
HardFault". Any future .data layout change could break this test the
same way.
Shrink the kernel's view of the 64 KiB SRAM by one KiB in the overlay
and move the fake registers into the carved-out tail, so no linker
layout can ever place kernel data under them.