fix process scanning on macos by properly listing memory regions #2033
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 process scanning on macos was broken since 4.2.0 in this commit: 605b2ed
Logic was added to properly iterate on memory chunks if a memory region is too big, but this completely broke the iteration. To retrieve a memory region, the code basically does:
It assumes that
addr
is smaller thancurrent_begin
, which is never the case outside of chunking. This leads to an iteration on completely wrong regions, leading to read that either fail because the starting addr or length is wrong, or that succeed, but do not cover the whole region.For example, with a process memory that looks like:
The very first call would have
current_begin=0
andaddr=0x1065a6000
, leading to underflow when computingchunk_size
, and trying to iterate on the region0x00000000-0x40000000
(as the max memory chunk is 1GB per default). this will fail to fetch, and will then iterate on0x40000000-0x80000000
, then0x80000000-0xC0000000
, then0xC0000000-0x100000000
. We will finally reach the very first real memory region, but fail to properly compute the region size with another underflow, etc.This commit fixes the issue by distinguishing the two cases:
addr > current_begin
:current_begin
is not in any memory region, and we must fast forward.addr <= current_begin
: we can compute the current chunk by diffing the two values.This bug was not detected by any tests because the test_process_scan was not running on macos: trying to scan the sh process always fails even when root, and the test was thus skipped. I hacked the test locally to check if it worked by replacing the sh process by something else that we can attach to, and it showed the scanning fails. With this commit, the test does pass.
I did not commit any modification to the test as I used a custom binary for this and it needs to be run as root, but it would probably be a good idea to adapt it.