Kernel panics on M5 devices with network extension

Question

Created Apr ’26

Replies 38

Boosts 2

Views 4.2k

Participants 14

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.

Answered by DTS Engineer in 883112022

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

Answer 1

Sagar115 OP

May ’26

Uploaded another kernel panic file to my case as I had another crash today.

Answer 2

dan.snelson OP

May ’26

AppleCare Enterprise Support Case Number: 102883075865

Answer 3

Sagar115 OP

May ’26

@DTS Engineer - Any update on these recent feedbacks & cases, with the issue still being known?

Answer 4

DTS Engineer OP

Apple

May ’26

@DTS Engineer - Any update on these recent feedbacks & cases, with the issue still being known?

So, the most recently reported issue is in fact a different panic than the previous one, though it's likely that it was masked by the earlier one (which occurred much more frequently). In any case, the engineering team is actively working on a fix, and it's likely that the fix will ship in a future software update.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Answer 5

Sagar115 OP

3w

@DTS Engineer - Any update on this being fixed in 26.6? I see that the 26.6 Developer Beta has been released.

Answer 6

DTS Engineer OP

Apple

3w

@DTS Engineer -

I don't mind if you call me Kevin.

Any update on this being fixed in 26.6?

Thanks for reminding me about this...

I see that the 26.6 Developer Beta has been released.

...and, yes, the most recently reported issue (r.174287383) should be fixed in the latest seed, macOS 26.6 (25G5028f).

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Answer 7

Sagar115 OP

2w

@DTS Engineer - Thank you for this! Hoping this is the last of this thread.

image (13).png

Answer 8

Hamashareef OP

2w

same issue happened to me, even i have installed Mac OS 26.5.1, is to going to beta verion?

macbook pro m5 pro, tonight happened 3 times, 2 time only in 5 minutes.

Gemini Check for logs:

This is a hardware-related kernel panic. The log pinpoints a specific error inside the silicon of your Mac's Apple Silicon chip.

Here is the exact breakdown of what happened and what you need to do next.

The Smoking Gun: What the Log Says The critical line is right at the top:

panic(cpu 9 caller 0xfffffe003fa8fb54): LLC single-bit ECC counter overflow error... (LLC correctable overflow)

Answer 9

Hamashareef OP

1w

@DTS Engineer

there is any new update coming? for fixing this issue Mr?

Answer 10

DTS Engineer OP

Apple

1w

same issue happened to me, even i have installed Mac OS 26.5.1, is to going to beta verion?

As I noted above, this issue is being addressed in macOS 26.6:

"...and, yes, the most recently reported issue (r.174287383) should be fixed in the latest seed, macOS 26.6 (25G5028f)."

Gemini Check for logs:

This is a hardware-related kernel panic. The log pinpoints a specific error inside the silicon of your Mac's Apple Silicon chip.

It's possible that AI has a useful role in kernel panic investigation, but I wouldn't expect commonly available consumer services to be all that useful.

panic(cpu 9 caller 0xfffffe003fa8fb54): LLC single-bit ECC counter overflow error... (LLC correctable overflow)

This is a different than the previously reported panic, but it's also very unlikely that the overflow described above is actual cause. That's not really how kernel panics work.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Answer 11

Hamashareef OP

1w

Thanks for your response

i submitted a new case after updating to MacOS 26.6 Beta, i have the same crash two times in 30 minutes

here the case number, thanks FB23099738

Answer 12

Hamashareef OP

3d

@DTS Engineer

Answer 13

DTS Engineer OP

Apple

2d

I submitted a new case after updating to macOS 26.6 Beta. I have the same crash two times in 30 minutes.

Here is the case number, thanks FB23099738.

I'm not sure what to make of that panic, but my initial read is that it's completely unrelated to the panics this thread is tracking. Symbolicating the log, this is the call stack:

Kernel Frames
 0  kernel.release.t6050  0xfffffe000b724870  DebuggerTrapWithState + 108 (debug.c:854)
 1  kernel.release.t6050  0xfffffe000b723e80  panic_trap_to_debugger + 1088 (debug.c:1467)
 2  kernel.release.t6050  0xfffffe000c05b1c8  panic + 60 (debug.c:1219)
 3  kernel.release.t6050  0xfffffe000b9084b4  generic_platform_error_handler + 1212 (peh.c:1161)
 4  kernel.release.t6050  0xfffffe000b8df994  sleh_serror + 152 (sleh.c:4691)
 5  kernel.release.t6050  0xfffffe000b6d2064  fleh_serror + 24
 6  kernel.release.t6050  0xfffffe000b8d472c  mach_syscall + 380 (bsd_arm64.c:298)
 7  kernel.release.t6050  0xfffffe000b8d472c  mach_syscall + 380 (bsd_arm64.c:298)
 8 kernel.release.t6050 0xfffffe000b8db798 sleh_synchronous + 2308 (sleh.c:1531)
 9 kernel.release.t6050 0xfffffe000b6d1ee4 fleh_synchronous + 72
10                                            [1, 0]

User Frames
0 libsystem_kernel.dylib   0x1804adc34 mach_msg2_trap + 8
1 libsystem_kernel.dylib   0x1804b69c0 mach_msg_overwrite + 480 (mach_msg.c:0)
2 libsystem_kernel.dylib   0x1804adfc0 mach_msg + 24 (mach_msg.c:323)
3                                        [393, 12070624]

...which basically means "you panicked making a syscall". I don't have any explanation for that except that it seems quite strange and seems to have been happening on 26.5 as well (on this same machine). I'm passing the panic to a few colleagues to see if they have any idea, but there's no indication that this is tied to the original network extension issue.

Please start a new thread for this and we can continue any investigation there.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware