fix(native): clamp module count

[jpnurmi]

Clamp module_count from shared crash context before indexing the fixed module array while enriching frames and debug metadata.

Unvalidated module_count from shared memory causes out-of-bounds array access

Details

In build_native_crash_event, ctx->module_count from shared memory crash context is used as a loop bound to index into ctx->modules[], a fixed-size array of SENTRY_CRASH_MAX_MODULES (512) elements. No validation ensures module_count <= 512 before the loop. The same unbounded iteration exists in enrich_frame_with_module_info at line 499. The crash context is shared memory filled by a crashing process's signal handler — memory corruption is precisely the scenario where this code runs. The developers recognized this risk and added a defensive bounds check in the minidump writer (sentry_minidump_macos.c:758-760 with comment 'Bounds check to prevent out-of-bounds access on corrupted crash context'), but did not apply the same protection to build_native_crash_event.

Location

src/backends/native/sentry_crash_daemon.c:2046

Impact

Crash daemon reads past fixed-size array from corrupted shared memory

Reproduction steps

1. A process crashes due to a heap buffer overflow that corrupts the shared memory crash context, setting module_count to 0xFFFF. The crash daemon reads this corrupted value and iterates 65535 times over a 512-element array, reading adjacent shared memory. This causes either a secondary crash in the daemon (preventing crash reports from being captured) or inclusion of leaked memory contents in the crash event sent to Sentry.

Recommended fix

module_count must be clamped to SENTRY_CRASH_MAX_MODULES before use as a loop bound, matching the defensive check already present in the minidump writer.

---

Severity: MEDIUM
Status: Open
Category: Buffer overflow
Repository: getsentry/sentry-native
Branch: master