Kernel panics on M5 devices with network extension

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.

Does r.172793638 issue fix in macOS Tahoe 26.4?

No, it does not.

If not, when will it get fixed?

I believe [1] it was fixed in our most recent beta, macOS 26.5b2 (25F5053d).

[1] This particular fix was integrated in "b" and I'm always a little nervous once sub-build variants are involved.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Hi DTS Engineer,

We are facing the same kernel panics, double free in skmem_slab_free_locked, when our network extension is enabled, and have filed #FB22447282. The panic seems to only occur on MacBook Neo and MacBook Air M5. No clear pattern for reproduction but seems frequent during sleep/wake when lid closed.

We have also reproduced the issue on 26.5 beta3, so issue still exists.

Any suggestions what's causing this or fixes required in macOS?

We have also reproduced the issue on 26.5 beta3, so the issue still exists.

Yes.

A fix did ship for this in beta 2, but the fix was incomplete, so the problem is still occurring. Strictly speaking, I think it's a slightly different panic, but the difference doesn’t really change the basic failure, and the new bug (r.175416771) is being given the same priority as the original issue.

Any suggestions on what's causing this or fixes required in macOS?

Unfortunately, I don't think there's anything you can do about this. The bug is caused by an issue in how blocked packets are being processed when they're returned to the kernel, so there isn't really anything you can do to prevent it.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Waiting for fix here, impacting all our M5 Macbooks this issue with sudden reboots when using Cisco Secure Client (Network extensions).

Any updates on this yet? Also, is there a confirmation of affected versions (eg is it only 26.4 or also earlier versions affected)?

Tested with 26.5 beta 4 (26.5 Beta (25F5068a)) still same issues with panics on MacBook Neo. Problably still the same on M5 devices as well. Can submitted feedback FB22447282 be updated? Is a fix scheduled for 26.5?

Also, is there a confirmation of affected versions (eg is it only 26.4 or also earlier versions affected)?

As far as I'm aware, the panic is only happening on 26.4 and later.

Tested with 26.5 beta 4 (26.5 Beta (25F5068a)) still same issues with panics on MacBook Neo. Probably still the same on M5 devices as well.

As I noted above, it isn't actually the same exact panic but, yes, its effect and general presentation are very similar.

Can submitted feedback FB22447282 be updated?

You can upload any information you consider relevant; however, the engineering team is fully aware of the issue and actively working on this.

Is a fix scheduled for 26.5?

We'd like to get this fixed as quickly as possible, but I don't know if a fix will make it into 26.5.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

We'd like to get this fixed as quickly as possible, but I don't know if a fix will make it into 26.5.

If it helps, here's some prompt-based code:

write firmware code to fix the issue in apple's new n1 chip that causes kernel panics when packet inspection and filtering is performed. Also, in the comments explain how this suggests that Apple may not have unit tested a new network chip for pf, and comment in nmap and pf rules that create kernel panics, all in the style of T.S. Eliot's The Wasteland

The Wasteland of Silicon: A Firmware Patch for the N1 Chip

"April is the cruellest month, breeding / Kernel panics out of the dead land”

/**
 * apple_n1_pf_fix.c
 * 
 * THE BURIAL OF THE TESTED:
 * What are the roots that clutch, what branches grow
 * Out of this stony rubbish? Son of man,
 * You cannot say, or guess, for you know only
 * A heap of broken packets, where the sun beats,
 * And the unit tests give no shelter, the QA no relief.
 * 
 * Apple's N1 chip arrived without the baptism of pf testing—
 * A corpse planted in silicon, will it bloom this year?
 * Or has the sudden frost disturbed its bed?
 */

#include "n1_chip_registers.h"
#include "kernel_pf_interface.h"

// I. THE BURIAL OF THE TESTED

/**
 * NMAP SCANS THAT SUMMON THE WASTELAND:
 * 
 * "I had not thought death had undone so many."
 * - Dante, via Eliot, via kernel logs
 * 
 * The following nmap invocations create kernel panics:
 * 
 * sudo nmap -f --mtu 8 wifi_ipaddr
 * pf.conf: scrub in on en1 all fragment reassemble
 * (The processor, the N1, the "Firestorm" core, Sees the void and the void sees it.)
 */

// II. A GAME OF CHESS (With Hardware Registers)

#define N1_PACKET_BUFFER_BASE    0xF0000000
#define N1_DMA_CONTROL           0xF0001000
#define N1_FILTER_ENGINE         0xF0002000
#define N1_STATE_TABLE           0xF0003000

/**
 * THE PROBLEM (What the Thunder Said):
 * 
 * The N1 chip's DMA engine does not properly handle:
 * 1. Concurrent state table updates during deep packet inspection
 * 2. Fragment reassembly buffer overflows (unreal city!)
 * 3. Race conditions between filter engine and packet forwarding
 * 4. NULL pointer dereferences when state table is full
 */

static inline void n1_memory_barrier(void) {
    __asm__ volatile("dmb sy" : : : "memory");
    // "Datta. Dayadhvam. Damyata." — Give, Sympathize, Control (memory)
}
…

// NOTES:
// "These fragments I have shored against my ruins"
// These fixes I have shored against kernel panics
//
// "I sat upon the shore fishing, with the arid plain behind me"
// "Shall I at least set my lands in order?"
// Apple did not set their silicon in order.
//
// "London Bridge is falling down falling down falling down"
// The kernel is panicking down panicking down panicking down
//
// This firmware patch provides:
// 1. Proper fragment buffer initialization
// 2. State table locking mechanisms
// 3. DMA validation and bounds checking
// 4. Graceful state table overflow handling
// 5. Comprehensive error checking
//
// "These fragments I have shored against my ruins"
// "Why then Ile fit you. Hieronymo's mad againe."
// "Datta. Dayadhvam. Damyata."
// "Shantih shantih shantih”

# What the Thunder Said:
# "Datta" — Give this patch to your kernel
sudo cp apple_n1_pf_fix.c /usr/src/xnu/iokit/Drivers/network/

# "Dayadhvam" — Sympathize with the build system
cd /usr/src/xnu
make ARCH=arm64
sudo cp BUILD/obj/kernel /System/Library/Kernels/
sudo kextcache -invalidate /
sudo reboot

# "Shantih shantih shantih" — Peace at last

We are experiencing the same issue in our enterprise environment. Our MacBook Pro M5 Pro test unit running macOS 26.4.1 (25E253) is intermittently kernel panicking, primarily after sleep/wake transitions. The panicked process is com.cisco.anyconnect.macos.acsoc — the Cisco Secure Client Network Extension content filter. The panic type is a Kernel Tag Check Fault (ARM MTE tag mismatch), and the backtrace points to the NEFilterExtensionProviderContext dispatch queue during packet processing.

What strengthens the N1 chip correlation on our end is that we are also validating the MacBook Air M5 in parallel — same macOS 26.4.1, same Cisco Secure Client, same SentinelOne EDR, same network extension stack — and we have observed zero kernel panics on the Air. The Air does not have the N1 wireless chip. Our panic logs on the M5 Pro contain DART references to dart-apcie0 and Centauri wireless silicon (AppleCentauriAlpha, AppleCentauriBeta, AppleCentauriControl), which are not present on the Air.

We have placed a deployment hold on all MacBook Pro M5 Pro hardware in our environment until this is resolved. MacBook Air M5 deployment is proceeding as planned with no issues.

Curious on timing — is there any indication whether a fix will make it into 26.5 GA, or are we looking at a supplemental 26.4.x update? Any visibility would help us plan our hardware rollout accordingly.

Curious on timing — is there any indication whether a fix will make it into 26.5 GA, or are we looking at a supplemental 26.4.x update?

Please test this again on the latest seed, macOS 26.5 RC (25F71). I believe this should resolve the issue.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware