stack_pivot: false positives on Go 1.26 binaries due to heap base randomization

[josedonizetti]

Description

Go 1.26 introduces heap base address randomization on 64-bit platforms (release notes). This breaks the stack_pivot detector's Go
heap recognition, causing false positive events for any Go 1.26 binary running on a monitored system.

Root Cause

The eBPF function vma_is_golang_heap() in pkg/ebpf/c/common/memory.h identifies Go heap arenas by checking if the VMA address falls in the
0xc000000000–0xff00000000 range (x86_64). This works because Go has historically allocated heap arenas at deterministic addresses starting at 0xc000000000.

Go 1.26 randomizes the heap base address as a security hardening measure. The arenas can now start at addresses outside the expected range, so
vma_is_golang_heap() returns false and the VMA is classified as VMA_ANON instead.

Since goroutine stacks live on the Go heap, the check_stack_pivot() function sees a syscall with SP pointing to anonymous memory (not the OS thread stack) and
emits a stack pivot event — a false positive.

Impact

Any Go 1.26 binary running on a system monitored by tracee will generate false positive stack_pivot events. This will worsen as Go 1.26 adoption increases, and
the GOEXPERIMENT=norandomizedheapbase64 opt-out is expected to be removed in a future Go release.

Reproduction

Build any Go 1.26 program and run it under tracee with the stack_pivot event enabled. Goroutine syscalls will trigger false positives with vma_type=anonymous.

The E2E test e2e-stack_pivot reproduces this reliably — the ds_writer Go test helper gets flagged.

Current Workaround

Tracee is built with GOEXPERIMENT=norandomizedheapbase64 to disable heap randomization in its own binaries and test helpers. This does not fix detection for
external Go 1.26 processes.

see #5244