Kernel panics on M5 devices with network extension
Hello,
We have a security solution which intercepts network traffic for inspection using a combination of Transparent Proxy Provider and Content filter.
Lately we are seeing reports from the market that on M5 Macbooks and A18 Neos the system will kernel panic using our solution, even though it never happens on M1-M4 and no significant code changes were made in the mean time. All crashes seem to be related to an internal double free in the kernel:
panic(cpu 0 caller 0xfffffe003bb68224): skmem_slab_free_locked: attempt to free invalid or already-freed obj 0xf2fffe29e15f2400 on skm 0xf6fffe2518aaa200 @skmem_slab.c:646
Debugger message: panic
Memory ID: 0xff
OS release type: User
OS version: 25D2128
Kernel version: Darwin Kernel Version 25.3.0: Wed Jan 28 20:54:38 PST 2026; root:xnu-12377.91.3~2/RELEASE_ARM64_T6050
Additionally, from further log inspection, before panics we find some weird kernel messages which seem to be related to some DMA operations gone wrong in the network driver on some machines:
2026-03-30 14:11:21.779124+0300 0x30f2 Default 0x0 873 0 Arc: (Network) [com.apple.network:connection] [C9.1.1.1 IPv4#e5b4bb04:443 in_progress socket-flow (satisfied (Path is satisfied), interface: en0[802.11], ipv4, ipv6, dns, uses wifi, flow divert agg: 1, LQM: good)] event: flow:start_connect @0.075s
2026-03-30 14:11:21.780015+0300 0x1894 Default 0x0 0 0 kernel: (402262746): No more valid control units, disabling flow divert
2026-03-30 14:11:21.780017+0300 0x1894 Default 0x0 0 0 kernel: (402262746): Skipped all flow divert services, disabling flow divert
2026-03-30 14:11:21.780102+0300 0x1894 Default 0x0 0 0 kernel: SK[2]: flow_entry_alloc fe "0 proc kernel_task(0)Arc nx_port 1 flow_uuid D46E230E-B826-4E0A-8C59-4C4C8BF6AA60 flags 0x14120<CONNECTED,QOS_MARKING,EXT_PORT,EXT_FLOWID> ipver=4,src=<IPv4-redacted>.49703,dst=<IPv4-redacted>.443,proto=0x06 mask=0x0000003f,hash=0x04e0a750 tp_proto=0x06"
2026-03-30 14:11:21.780194+0300 0x1894 Default 0x0 0 0 kernel: tcp connect outgoing: [<IPv4-redacted>:49703<-><IPv4-redacted>:443] interface: en0 (skipped: 0)
so_gencnt: 14634 t_state: SYN_SENT process: Arc:873 SYN in/out: 0/1 bytes in/out: 0/0 pkts in/out: 0/0 rtt: 0.0 ms rttvar: 250.0 ms base_rtt: 0 ms error: 0 so_error: 0 svc/tc: 0 flow: 0x9878386f
2026-03-30 14:11:21.934431+0300 0xed Default 0x0 0 0 kernel: Hit error condition (not panicking as we're in error handler):
t8110dart <private> (dart-apcie0): invalid SID 2 TTBR access: level 1 table_index 0 page_offset 0x2
2026-03-30 14:11:21.934432+0300 0xed Default 0x0 0 0 kernel: [ 73.511690]: arm_cpu_init(): cpu 6 online
2026-03-30 14:11:21.934441+0300 0xed Default 0x0 0 0 kernel: [ 73.511696]: arm_cpu_init(): cpu 9 online
2026-03-30 14:11:21.934441+0300 0xed Default 0x0 0 0 kernel: [ 73.569033]: arm_cpu_init(): cpu 6 online
2026-03-30 14:11:21.934441+0300 0xed Default 0x0 0 0 kernel: [ 73.569038]: arm_cpu_init(): cpu 9 online
2026-03-30 14:11:21.934442+0300 0xed Default 0x0 0 0 kernel: [ 73.577453]: arm_cpu_init(): cpu 7 online
2026-03-30 14:11:21.934442+0300 0xed Default 0x0 0 0 kernel: [ 73.586328]: arm_cpu_init(): cpu 5 online
2026-03-30 14:11:21.934442+0300 0xed Default 0x0 0 0 kernel: [ 73.586332]: arm_cpu_init(): cpu 8 online
2026-03-30 14:11:21.934442+0300 0xed Default 0x0 0 0 kernel: [ 73.621392]: (dart-apcie0) AppleT8110DART::_fatalException: dart-apcie0 (<ptr>): DART DART SID exception ERROR_SID_SUMMARY 0x00003000 ERROR_ADDRESS 0x0000000000009800
2026-03-30 14:11:21.934443+0300 0xed Default 0x0 0 0 kernel: [ 73.621397]: Hit error condition (not panicking as we're in error handler):
2026-03-30 14:11:21.934443+0300 0xed Default 0x0 0 0 kernel: t8110dart <ptr> (dart-apcie0): invalid SID 2 TTBR access: level 1 table_index 0 page_offset 0x2Expect a `deadbeef` in the error messages below
2026-03-30 14:11:21.934452+0300 0xed Default 0x0 0 0 kernel: Expect a `deadbeef` in the error messages below
2026-03-30 14:11:21.934456+0300 0xed Default 0x0 0 0 kernel: (AppleEmbeddedPCIE) apcie[0:centauri-control]::_dartErrorHandler() InvalidPTE caused by read from address 0x9800 by SID 2 (RID 2:0:1/useCount 1/device <private>)
2026-03-30 14:11:21.934469+0300 0xed Default 0x0 0 0 kernel: (AppleT8110DART) Ignored dart-apcie0 (0xfbfffe18820b0000): DART(DART) error: SID 2 PTE invalid exception on read of DVA 0x9800 (SEG 0 PTE 0x2) ERROR_SID_SUMMARY 0x00003000 TIME 0x11242d43fd TTE 0xffffffffffffffff AXI_ID 0
We do not have any correlation between machines, usage pattern or installed applications. Uninstalling the network protection features seem to largely fix the issues, even though we have heard of crashes happening even in safe mode or with our network extension disabled from system settings.
We weren't able to reproduce internally and it seems to happen completely random on client machines, but often enough to be disrupting.
Can you tell us please if this is a known problem and if there's a workaround or what can we do to narrow it down?
Thanks.
I submitted FB22401652 with multiple kernel panics attached.
Perfect and, yes, this is the panic I mentioned earlier (r.172793638). In terms of what you can do about it, I don't think there really is anything. The bug itself is already a high priority issue and your components involvement appears to be fairly peripheral.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
Lately we are seeing reports from the market that on M5 Macbooks and A18 Neos the system will kernel panic using our solution, even though it never happens on M1-M4 and no significant code changes were made in the mean time. All crashes seem to be related to an internal double free in the kernel:
Have you filed a bug on this and, if so, what's the bug number?
Can you tell us please if this is a known problem and if there's a workaround or what can we do to narrow it down?
I'm need full panic logs to be sure (that's why I asked about the bug) but, yes, I suspect this is a known issue (r.172793638).
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
Hello Kevin,
I submitted FB22401652 with multiple kernel panics attached.
Thanks!
I submitted FB22401652 with multiple kernel panics attached.
Perfect and, yes, this is the panic I mentioned earlier (r.172793638). In terms of what you can do about it, I don't think there really is anything. The bug itself is already a high priority issue and your components involvement appears to be fairly peripheral.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
Does r.172793638 issue fix in macOS Tahoe 26.4? If not, when will it get fixed?
I don't think it's fixed, Just starting yesterday, two of our Apple Silicon Macs (M4) at the office running 26.4 and now 26.4.1, are experiencing a kernel panic and force reboot when attempting to connect to a Windows 11 File server SMB share. I came here looking for posts related to it, and ended up here. Also searched on Google and this problem has been happening to a lot of folks on 26.4. Please Apple, get this fixed ASAP, it is affecting out ability to work.