https://orbstack.dev logo
Powered by
Reproducible kernel panic on launch — OrbStack Hel...
# support
a
Summary Launching OrbStack reliably kernel-panics the Mac within ~1 minute. Because OrbStack auto-starts at login, this produced a panic→reboot→panic loop (machine unusable until OrbStack was disabled). Every panic is in the 
OrbStack Helper
(VM manager) task, with kernel heap corruption in zone 
data.kalloc.1024
. Environment - OrbStack: 2.2.1 (build 20628) - macOS: 27.0 (build 26A5353q) — pre-release/beta seed - Hardware: Mac mini 
Mac16,10
, Apple M4 (SoC T8132) - Kernel: 
Darwin 27.0.0: xnu-13361.0.0.501.1~2/RELEASE_ARM64_T8132
Reproducibility: 100%. 7 panics in ~30 min, every one triggered by OrbStack starting (6 on login auto-start; 1 when I manually invoked 
orbctl
). Panic fires within ~60s of the engine starting.
Panicked process (every time): 
pid …: OrbStack Helper
— task has ~82 threads, ~188k pages resident at panic. Panic strings (two related signatures, same zone):
Copy code
panic(...): zfree_drop: double free of 0x… to zone data.kalloc.1024 @zalloc.c:807
panic(...): [data.kalloc.1024]: element modified after free (off:0, val:0x809a9ff0809a9ff0, sz:1024, ptr:0x…)
So: a 1024-byte kernel allocation is being freed twice / used after free from the OrbStack Helper context — classic UAF heap corruption. Forensic detail: in the "modified after free" panic, the freed 1024-byte slab had been reallocated to hold a filesystem path string before the stale write hit it. Decoding the tail bytes gives:
Copy code
/Volumes/fast/media/downloads/active
(i.e. an external/secondary volume named 
fast
) — may hint the corruption involves VM disk/volume/path handling. Kernel backtrace of the panicking thread (slid addresses — full symbolicated stack is in the .panic files):
Copy code
lr: 0xfffffe005718035c
lr: 0xfffffe0057308ed8
lr: 0xfffffe0057306d98
lr: 0xfffffe005712f664
lr: 0xfffffe0057180680
lr: 0xfffffe0057aa20f4
lr: 0xfffffe0057aaba2c   <- zone free-check (data.kalloc.1024)
lr: 0xfffffe0057207078
... (full chain in attached panic-full-*.panic)
last branch to userspace: 0x0000000182a76680
Frequency / files: 7 full panic logs available: 
panic-full-2026-06-12-{164936,165036,165738,170507,170606,170708,171807}.panic
(in 
/Library/Logs/DiagnosticReports/
). Happy to attach all of them — they contain the complete stackshot and loaded-kext list. Workaround: OrbStack disabled (app relocated out of 
/Applications
, login item neutralized). System stable since.
d
please report this to apple using feedback assistant, or if you click report on the dialog after a reboot and let it collect+upload diagnostics it should do it for you
probably can't do much about this, looks like a macOS 27 beta 1 kernel bug
feel free to send one of the panic-full files too (in DM as it could contain sensitive info in the stackshot)
a
i had the same issue
i reported it to apple tho
memory tagging caught it which is cool
@Andrew has developer beta 2 fixed your issues?
p
Have the same issue and unfortunately still happens on beta 2.
d
can someone send a feedback ID from the report to apple? i'll see if i can get apple to look at it
should be in feedback assistant
p
FB23047104
c
FB23397578 (currently on Beta 2)
any workarounds (where we can stay on golden gate and still use orbstack)? 😅
d
not sure, i've been on beta 1 and 2 since they came out and everything works fine
so you can probably isolate something in your setup that's causing this
c
hmm super weird. what orbstack settings are you using?
d
in @Abu Hurayra's case i think it's related to SMB
c
Hmm have you seen this? Sounds related: https://github.com/orbstack/orbstack/issues/2562
a
yeah i was running bmake builds of os161 (in a devcontainer so there was some mounts) before my crashes (which would be definitely be doing a lot of disk I/O)
c
updated to beta 3, still getting kernel panics
a
bruh
p
Same, just had one after 19 hours up
Still occurring on the revised beta 3.
a
Is this the public beta? Damn bro
p
All good so far in Dev beta 4. Over 24 hours up.
PreviousNext
Powered by