Skip to content

fix(yara-memory): classify macOS regions by their own VM entry - #683

Merged
Karib0u merged 2 commits into
mainfrom
claude/ci-error-fix-baa99b
Oct 1, 2026
Merged

Karib0u merged 2 commits into
mainfrom
claude/ci-error-fix-baa99b

Conversation

@Karib0u

@Karib0u Karib0u commented Oct 1, 2026

Copy link
Copy Markdown
Owner

Summary

Fixes the flaky Tests (macOS) failure in memory_scan_finds_marker_in_own_process (run 36885026801). The test started running on macOS when #674 un-ignored it. The flake came from two real detection bugs in the macOS memory reader (src/memory/macos.rs).

1. Anonymous memory took the name of the next file mapping

proc_regionfilename (XNU PROC_PIDREGIONPATH) walks forward from the address to the next file-backed entry and returns that path. A malloc region sitting between dyld's segments was reported as /usr/lib/dyld, classified Mapped, and skipped. When the test's marker landed there, the scan missed it (about 1 in 20 runs locally).

The fix classifies with PROC_PIDREGIONPATHINFO, through libproc::proc_pid::pidinfo with a #[repr(C)] struct. Its layout was checked against the SDK headers on arm64 and x86_64 (1272 bytes), and a compile-time assert pins the size. A path is only accepted when the returned entry actually contains the address.

2. The dyld shared cache used up the scan budget as "private" memory

The shared cache's submaps and the slid __DATA/__LINKEDIT pieces between them have no backing path, so they counted as private. Under the default 64 MB budget the scan spent about 40 MB there and stopped around 0x1fb744000. It never reached the malloc regions above the cache (Malloc Small at 0x7b8b000000 on macOS 27). Measured on arm64 with default settings:

allocation before after
24 B, 2 KB (Malloc Tiny, low addresses) found found
16 KB, 64 KB, 200 KB, 4 MB never scanned found

Total private memory read dropped from 64 MB (budget exhausted) to 47 MB (whole process covered).

The fix: entries in a contiguous run that starts and ends with a PROC_REGION_SUBMAP entry are treated as shared-cache library memory. They are classified Image if executable, otherwise Mapped, matching Linux file-backed segments and Windows MEM_IMAGE. An address gap ends a run, so heaps between two separate shared regions are never swallowed. The config reference and docs/configuration.md note the macOS behavior.

Test plan

  • New anonymous_region_below_a_file_mapping_has_no_filename: fails on the old regionfilename lookup, passes now.
  • New shared_cache_spans_contiguous_runs_between_submaps (synthetic runs, gaps, trailing pieces) and own_shared_cache_is_found_and_excludes_the_heap (live process).
  • cargo test --test yara_memory: 0 failures in 200 runs locally, against about 1 in 20 before.
  • cargo clippy --locked --all-targets -- -D clippy::all, cargo fmt --check, and the full cargo test --locked pass on macOS arm64.
  • memory_scan_finds_marker_in_child_process (ignored) not verified: it needs root for task_for_pid on another process.

macOS memory scans misclassified two kinds of region, which made
memory_scan_finds_marker_in_own_process flaky on the macOS runner and hid
real heap memory from YARA.

proc_regionfilename walks forward to the next file-backed entry, so an
anonymous malloc region just below a mapping (for example between dyld's
segments) took that file's name and was skipped as Mapped. Classify with
PROC_PIDREGIONPATHINFO instead and check that the returned entry contains
the address.

The dyld shared cache was counted as private memory: its submaps and the
slid __DATA/__LINKEDIT pieces between them have no path. Under the default
64 MB budget it used about 40 MB before the scan reached the malloc regions
above it, so no allocation of 16 KB or more was ever scanned. Treat
contiguous runs bounded by submap entries as library memory (Image or
Mapped), matching Linux and Windows.
@Karib0u
Karib0u enabled auto-merge (squash) October 1, 2026 17:09
@Karib0u
Karib0u merged commit 1175955 into main Oct 1, 2026
17 checks passed
@Karib0u
Karib0u deleted the claude/ci-error-fix-baa99b branch October 1, 2026 17:16
@Karib0u Karib0u added the bug Something isn't working label Oct 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant