Kernel panic (data abort, near-null dereference) hit twice with an identical backtrace during normal elfuse/HVF guest execution

[doanbaotrung]

Kernel panic (data abort, near-null dereference) hit twice with an identical backtrace during normal elfuse/HVF guest execution

Summary

Host machine kernel-panicked twice in the same working session while running a long-lived Linux ELF guest process under elfuse, embedded as a library via guest_bootstrap_prepare/guest_bootstrap_create_vcpu. Both panics are a Kernel data abort — a translation fault dereferencing address 0x8 (i.e. a near-null pointer, offset 8 bytes into some struct) — and after subtracting out each boot's independent KASLR slide, the two panics are byte-for-byte the same crash: identical faulting PC offset, identical calling-function offset, and an identical 17-frame backtrace. This isn't two unrelated incidents; it's one deterministic, reproducible kernel bug.

Environment

• macOS 26.5.2 (25F84), Darwin Kernel Version 25.5.0: Tue Jun 9 22:28:24 PDT 2026; root:xnu-12377.121.10~1/RELEASE_ARM64_T6020
• Hardware model: Mac14,9
• Panic reports:

panic-full-2026-07-28-185937.0002.panic.log
panic-full-2026-07-28-182313.0002.panic.log

panic-full-2026-07-28-182313.0002.panicandpanic-full-2026-07-28-185937.0002.panic`

The two panics

	Panic 1	Panic 2
Timestamp	2026-07-28 18:23:13	2026-07-28 18:59:37
panic(cpu N caller ADDR)	cpu 3, caller 0xfffffe004d4a7d1c	cpu 3, caller 0xfffffe004b377d1c
pc	0xfffffe004cd496fc	0xfffffe004ac196fc
esr	0x0000000096000005	0x0000000096000005
far	0x0000000000000008	0x0000000000000008
Kernel text exec base	0xfffffe004cb54000	0xfffffe004aa24000

esr = 0x96000005 decodes to EC = 0x25 (Data Abort taken at the same Exception level — i.e. the kernel faulted while already in EL1) with DFSC = 0x05 (Translation fault, level 1). So: the kernel itself took a translation fault — tried to dereference an unmapped page — at virtual address 0x8 while already running in EL1. That's a classic "read a small field off a null pointer" bug shape.

Same bug, not a coincidence

Subtracting each boot's own kernel text base from pc and caller removes the per-boot KASLR slide and gives the load-address-independent offset into the kernel binary:

panic1 pc offset:     0x1f56fc      panic2 pc offset:     0x1f56fc      (match)
panic1 caller offset: 0x953d1c      panic2 caller offset: 0x953d1c      (match)

I went further and did this for the entire 17-frame lr backtrace chain from the panicked thread in both reports — every single frame offset matches exactly:

0x55808   0x55808   MATCH
0x1d4014  0x1d4014  MATCH
0x1d2054  0x1d2054  MATCH
0x597c    0x597c    MATCH
0x55b18   0x55b18   MATCH
0x94486c  0x94486c  MATCH
0x953d1c  0x953d1c  MATCH   <- this frame is the panic() caller
0x1d3e4c  0x1d3e4c  MATCH
0x1d224c  0x1d224c  MATCH
0x597c    0x597c    MATCH
0x1f56fc  0x1f56fc  MATCH   <- this frame is the faulting pc
0x1ddfdc  0x1ddfdc  MATCH
0xb7b28   0xb7b28   MATCH
0x7c55c   0x7c55c   MATCH
0x7c55c   0x7c55c   MATCH
0x7c484   0x7c484   MATCH
0x656c    0x656c    MATCH

Also worth noting: both panics show the same odd pair of register values, x5/x6 = 0xfeedfacefeedfad3 / ...fad3 or ...fad4 (varies by one nibble between the two). I'm not claiming this proves Mach-O parsing is directly involved — 0xfeedface shows up as a generic sentinel/poison pattern in other Apple kernel contexts too — but it's a consistent detail across both crashes and may be a useful lead.

What was actually running

This machine was running elfuse continuously for an extended session: repeatedly launching a Linux ELF guest process through the normal guest_bootstrap_prepare → vcpu_run_loop path, plus guest clone()/fork() → posix_spawn activity (per runtime/forkipc.c). Nothing exotic — this is the ordinary "run an ELF guest under HVF" path that's presumably exercised all the time. I want to flag one thing explicitly: this is unrelated to an RFC patch I was separately drafting (a --allow-host-exec fallback in sys_execve) — that code path is off by default and was never executed before either panic; the only command I'd run from that work at the time was a baseline test with the flag disabled, which only exercises the pre-existing elf_load_fd() rejection path. I'm reporting the panic here as its own issue because the evidence points at something already present in elfuse/HVF interaction, not at anything I added.

What I can't do from here

I don't have symbols for this exact kernel build, so I can't map 0x1f56fc (pc) / 0x953d1c (caller) to actual function names — that would immediately tell you where in HVF/elfuse's vCPU handling this is. If you have a symbolicated kernel or atos/kernel debug kit for Darwin 25.5.0 xnu-12377.121.10~1 RELEASE_ARM64_T6020, that offset pair plus the full 17-frame chain above should resolve quickly. Happy to run further diagnostics (with permission) or try to reproduce with more targeted logging if that's useful — full panic report files available on request.

[doanbaotrung]

Script that may help

#!/usr/bin/env bash
# repro-clone-stress.sh
#
# Best-effort attempt to reproduce a kernel data-abort panic (translation
# fault at address 0x8, ESR 0x96000005) observed twice with a byte-for-byte
# identical 17-frame kernel backtrace during an extended session of
# ordinary elfuse/HVF guest execution.
#
# IMPORTANT CAVEAT: this is NOT a confirmed minimal reproducer. There was
# no single isolated command available from the session where the panics
# occurred -- only the general shape of what was running at the time:
# many repeated Linux ELF guest launches through the normal
# guest_bootstrap_prepare -> vcpu_run_loop path, plus guest
# clone()/fork() -> posix_spawn activity (per runtime/forkipc.c). This
# script stresses exactly that shape -- repeated guest launches, each
# forking/backgrounding child processes inside the guest shell -- to
# maximize the chance of hitting whatever intermittent condition
# triggered the crash. It may or may not actually reproduce it.
#
# CAUTION: running this launches real Hypervisor.framework VMs repeatedly
# and is meant to try to reproduce a kernel panic. Run it only in a
# disposable VM / throwaway test machine, never on a primary machine.
#
# Usage: repro-clone-stress.sh [path-to-elfuse] [path-to-busybox] [iterations]
#   path-to-elfuse   default: ./build/elfuse (build via `make elfuse` first)
#   path-to-busybox  default: externals/test-fixtures/aarch64-musl/staticbin/bin/busybox
#                    (already vendored in the elfuse repo, no cross-compiler needed)
#   iterations       default: 500

set -u
ELFUSE="${1:-./build/elfuse}"
BUSYBOX="${2:-externals/test-fixtures/aarch64-musl/staticbin/bin/busybox}"
ITERATIONS="${3:-500}"

if [ ! -x "$ELFUSE" ]; then
    echo "elfuse binary not found/executable: $ELFUSE" >&2
    echo "(build it first with: make elfuse)" >&2
    exit 1
fi
if [ ! -x "$BUSYBOX" ]; then
    echo "busybox fixture not found/executable: $BUSYBOX" >&2
    exit 1
fi

echo "Running $ITERATIONS iterations of repeated guest launch + fork/clone against $ELFUSE ..."

for i in $(seq 1 "$ITERATIONS"); do
    "$ELFUSE" "$BUSYBOX" sh -c '
        # Exercise guest clone()/fork(): background jobs and a pipeline
        # both fork inside the guest.
        busybox echo iteration-child-a >/dev/null &
        busybox echo iteration-child-b >/dev/null &
        busybox echo iteration-pipe | busybox cat >/dev/null
        wait
    ' >/dev/null 2>&1
    status=$?
    if [ "$status" -gt 128 ]; then
        echo "iteration $i: elfuse process exited with signal-range status $status" >&2
    fi
    if [ $((i % 50)) -eq 0 ]; then
        echo "  ...$i/$ITERATIONS iterations completed"
    fi
done

echo "done: $ITERATIONS iterations completed without a hard crash of this script."
echo "(A kernel panic, if triggered, will show up as a host reboot -- this script cannot catch that itself.)"