[CUSTOMMEM] only track the newly added heap when brk changed#4055
Merged
Conversation
find31/47bitBlockNearHint re-tracked the whole heap from pbrk as RW every time the program break moved. setProtection only writes the tracking, not the kernel, so any page the guest had made executable inside the heap (JIT or hook trampolines) silently lost PROT_EXEC while the kernel still mapped it rwx, and CheckExec then raised 0xecec forever on it. Track only the range that was actually added. Fixes ptitSeb#4052
ptitSeb
reviewed
Jul 17, 2026
Owner
|
Thanks. |
This was referenced Jul 17, 2026
Closed
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
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.
Proper fix for #4052, replacing the CheckExec workaround in #4053.
find31bitBlockNearHint/find47bitBlockNearHintre-tracked the whole heap frompbrkas RW every time the program break moved.setProtectiononly writes the tracking, not the kernel, so every page the guest had made executable inside the heap silently lost PROT_EXEC in the tracking while the kernel still mapped it rwx.CheckExecthen saw prot=3 against a kernel 0x7 and raised 0xecec forever at that RIP.Hit it with UE4SS on a Palworld dedicated server: it puts hook trampolines on heap pages, the heap grows, the trampolines lose their exec bit in the tracking, and the server dies in a signal storm about one boot in three.
Now only the range actually added since last time is tracked, so existing heap pages keep their protection.
Tested on ARM64 (Neoverse-N1), Palworld dedicated server + UE4SS, 8 boots: no storm. I kept the CheckExec resync from #4053 in the test binary purely as a canary that logs when tracking and kernel disagree — with the same binary before this fix it fired on 5 of 8 boots, after it never fired once.
#4053 can be closed if you take this one.