On modern systems all KEXTs must be code signed with a Developer ID. Additionally, the Developer ID must be specifically enabled for KEXT development. You can learn more about that process on the Developer ID page. If your KEXT is having code signing problems, check that it’s signed with a KEXT-enabled Developer ID. Do this by looking at the certificate used to sign the KEXT. First, extract the certificates from the signed KEXT: % codesign -d --extract-certificates MyKEXT.kext Executable=/Users/quinn/Desktop/MyKEXT/build/Debug/MyKEXT.kext/Contents/MacOS/MyKEXT This creates a bunch of certificates of the form codesignNNN, where NNN is a number in the range from 0 (the leaf) to N (the root). For example: % ls -lh codesign* -rw-r--r--+ 1 quinn staff 1.4K 20 Jul 10:23 codesign0 -rw-r--r--+ 1 quinn staff 1.0K 20 Jul 10:23 codesign1 -rw-r--r--+ 1 quinn staff 1.2K 20 Jul 10:23 codesign2 Next, rename each of those certificates to include the .cer extension: % for i in codesign*; do mv $i $i.cer; done Finally, look at the leaf certificate (codesign0.cer) to see if it has an extension with the OID 1.2.840.113635.100.6.1.18. The easiest way to view the certificate is to use Quick Look in Finder. Note If you’re curious where these Apple-specific OIDs comes from, check out the documents on the Apple PKI page. In this specific case, look at section 4.11.3 Application and Kernel Extension Code Signing Certificates of the Developer ID CPS. If the certificate does have this extension, there’s some other problems with your KEXT’s code signing. In that case, feel free to create a new thread here on DevForums with your details. If the certificate does not have this extension, there are two possible causes: Xcode might be using an out-of-date signing certificate. Re-create your Developer ID signing certificate using the developer site and see if the extension shows up there. If so, you’ll have to investigate why Xcode is not using the most up-to-date signing certificate. If a freshly-created Developer ID signing certificate does not have this extension, you need to apply to get your Developer ID enabled for KEXT development per the instructions on the Developer ID page. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Change history: 20 Jul 2016 — First published. 28 Mar 2019 — Added a link to the Apple PKI site. Other, minor changes. 15 Mar 2022 — Fixed the formatting. Updated the section number in the Developer ID CPS. Made other minor editorial changes.

I'm debugging the following kernel panic to do with my custom filesystem KEXT: panic(cpu 0 caller 0xfffffe004cae3e24): [kalloc.type.var4.128]: element modified after free (off:96, val:0x00000000ffffffff, sz:128, ptr:0xfffffe2e7c639600) My reading of this is that somewhere in my KEXT I'm holding a reference 0xfffffe2e7c639600 to a 128 byte zone that wrote 0x00000000ffffffff at offset 96 after that particular chunk of memory had been released and zeroed out by the kernel. The panic itself is emitted when my KEXT requests the memory chunk that's been tempered with via the following set of calls. zalloc_uaf_panic() __abortlike static void zalloc_uaf_panic(zone_t z, uintptr_t elem, size_t size) { ... (panic)("[%s%s]: element modified after free " "(off:%d, val:0x%016lx, sz:%d, ptr:%p)%s", zone_heap_name(z), zone_name(z), first_offs, first_bits, esize, (void *)elem, buf); ... } zalloc_validate_element() static void zalloc_validate_element( zone_t zone, vm_offset_t elem, vm_size_t size, zalloc_flags_t flags) { ... if (memcmp_zero_ptr_aligned((void *)elem, size)) { zalloc_uaf_panic(zone, elem, size); } ... } The panic is triggered if memcmp_zero_ptr_aligned(), which is implemented in assembly, detects that an n-sized chunk of memory has been written after being free'd. /* memcmp_zero_ptr_aligned() checks string s of n bytes contains all zeros. * Address and size of the string s must be pointer-aligned. * Return 0 if true, 1 otherwise. Also return 0 if n is 0. */ extern int memcmp_zero_ptr_aligned(const void *s, size_t n); Normally, KASAN would be resorted to to aid with that. The KDK README states that KASAN kernels won't load on Apple Silicon. Attempting to follow the instructions given in the README for Intel-based machines does result in a failure for me on Apple Silicon. I stumbled on the Pishi project. But the custom boot kernel collection that gets created doesn't have any of the KEXTs that were specified to kmutil(8) via the --explicit-only flag, so it can't be instrumented in Ghidra. Which is confirmed as well by running: % kmutil inspect -B boot.kc.kasan boot kernel collection at /Users/user/boot.kc.kasan (AEB8F757-E770-8195-458D-B87CADCAB062): Extension Information: I'd appreciate any pointers on how to tackle UAFs in kernel space.

Filed as FB23904785 with pcaps, a mid-episode sysdiagnose, & a userspace test harness. Posting here because the behavior localizes to the receive-window computation in xnu & I'd value a sanity check from anyone who knows what changed in this area for 27. On 26A5378n (MacBook Air M2, RTL8156B 2.5GbE via the in-kernel AppleUSBNCM driver), TCP downloads on the wired interface intermittently drop to 6-10 Mbps for stretches of minutes to 40 minutes, then recover on their own. Wi-Fi on the same machine pulls 50-70 Mbps from the same servers in the same seconds. Packet captures show why: during these stretches the kernel advertises a 5,440-byte receive window from the first post-handshake ACK & doubles it on 1.000 s ± 0.01 s wall-clock boundaries, seven doublings in a row, in two separate connections started 6.5 minutes apart, while bytes-per-interval varied 16x. Byte-count triggers can't produce byte-rate-invariant timing; that's a clock. What I ruled out inside a live occurrence: SO_RCVBUF of 4 MB (getsockopt-verified; identical staircase, so it isn't autotuning), ECN on/off (three toggles, no change), both link_heuristics sysctls, the WAN (during one occurrence ICMP loss was WORSE on Wi-Fi, 20% vs 10%, yet Wi-Fi ran 5x faster), & the wire itself (0.1% retransmissions, ACK timestamp-echo p50 43 ms, zero zero-window advertisements). TCP_CONNECTION_INFO confirms the on-wire numbers: tcpi_rcv_wnd 10,880 at t=2 s against a 4 MB buffer that stays 97% empty, tcpi_srtt 41 ms. The throttled flow itself hit 32.7 Mbps at t=7 s once the staircase reached 347 KB, so path capacity was there the whole time. The signature resembles a receiver-side LEDBAT governor (RFC 9840 describes exposing a reduced window through the receive window; tcp_rledbat.c in published xnu clamps recwin for sockets flagged receive-background). Two things don't add up though. First, I ported the published tcp_rledbat.c to userspace & drove it with the exact packet timeline from my capture: no parameterization reproduces constant 2x steps on one-second boundaries, because every growth law in that file counts bytes or RTTs, not seconds. Second, kern.ipc.throttle_best_effort reads 1 on a clean boot of this beta with no sysctl.conf, no profiles, & no third-party launch items, while published xnu initializes it to 0. That switch arms the demotion of best-effort sockets to receive-background on interfaces that recently carried realtime-marked traffic. Questions: did the receive-window governor change in 27, & did the throttle_best_effort default flip intentionally? And is there a supported way to see which sockets carry SOF1_TRAFFIC_MGT_TCP_RECVBG at runtime, to pin down what's marking these flows? Happy to attach anything from the evidence set to the FB or run diagnostics on request; the fault reproduces several times a day here.

We are building a KPI(Telemetry) analytics reporting feature in our iOS app that requires recording and publishing reliable timestamps back to our backend server. Standard system time (Date()) is not suitable for our use case because it is susceptible to manual user changes (system clock manipulation) as well as clock drift over time. We are considering clock_gettime_nsec_np(CLOCK_MONOTONIC_RAW ) as a potential solution for iOS 10+. However, we want to confirm: Is clock_gettime_nsec_np a reliable, drift-free source for this purpose? Does the underlying OS handle NTP synchronization for these clocks, or can user-level time changes still impact them? Additionally, we recently came across Apple's official swift-ntp client library to fetch true NTP time directly. For production KPI reporting, is relying on an NTP library like swift-ntp the recommended approach, or is clock_gettime_nsec_np sufficient on modern iOS? We’d appreciate any insights or past experiences from the community. Thanks!

Hi all, Working on a personal-use kernel extension (not for distribution, just my own Mac) and hitting a wall between Reduced Security and notarization. A lot of existing threads on this are from 2018–2022, so hoping someone can confirm what's still current. Setup: Apple Silicon, macOS 27 (Golden Gate beta) Boot Security Policy: Reduced Security with "Allow user management of kernel extensions from identified developers" enabled (confirmed via bputil -d) Standard $99/year Developer Program membership Kext signed with a standard Developer ID Application cert (via normal CSR through Keychain Access) What happened: codesign -dvvv shows a clean signature — valid Authority chain, correct TeamIdentifier, timestamped. No issues. But kmutil load -p rejects it: Authenticating extension failed: Bad code signature I understood from an older DTS reply that notarization was the missing piece, so I ran it through notarytool. Upload/auth succeeded, but the result came back Invalid: { "severity": "error", "message": "The binary is not signed with a valid Developer ID certificate.", "architecture": "arm64e" } Question: Is a standard Developer ID Application cert genuinely insufficient for kext notarization, and is the kext-signing entitlement (via /contact/kext/) still the only way to get a cert with the right extension (OID 1.2.840.113635.100.6.1.18)? Or has this changed for personal use recently? Apple's own Contact page for that form says: "You don't need to request a certificate to sign your kernel extension for personal use... signature checking can be disabled as described in the SIP Guide." That implies Reduced Security + personal kext shouldn't need the special cert — but my results suggest otherwise. Am I missing a step, or is there a documentation gap? Happy to share kmutil print-diagnostics output if useful. Thanks!

A brand-new MacBook Pro (M5 Pro, 24GB RAM) is experiencing frequent, severe kernel panics. The system freezes completely for a few seconds before executing an automatic reboot or shutdown. This behavior occurs roughly 10+ times per day, significantly disrupting production work. The issue initially triggered immediately after migrating data from a base M4 MacBook Pro via Migration Assistant. Steps Taken & Troubleshooting Hardware Diagnostics: Ran Apple Diagnostics locally; all hardware checks passed with no errors detected. OS Updates: Installed the minor macOS patch intended to resolve M5 automatic reboot bugs. The issue persisted. System Erase: Performed a complete factory reset ("Erase All Content and Settings") and a clean OS reinstallation as advised by Apple Support. Beta Testing: Upgraded to the macOS Tahoe Beta following guidance from a DST Engineer who indicated the issue was addressed in this build. The frequent crashes continue to occur on the beta track. Case / Feedback Reference Feedback ID: FB23273513 (Captured after the system format)

After two consecutive crashes, I found this log. The first crash happened when I was using Veracrypt to decrypt an external disk and selecting the drive, and the second crash happened on the lock screen when unlocking my Mac. Is this caused by Veracrypt or a system design flaw? Veracrypt relies on Fuse-T, and it's the same on Linux—you need to install lib-fuse to use it. Veracrypt Version:1.26.29(Fuse-T Build) Debugger message: panic Memory ID: 0xff OS release type: User OS version: 25F80 Kernel version: Darwin Kernel Version 25.5.0: Mon Apr 27 20:41:22 PDT 2026; root:xnu-12377.121.6~2/RELEASE_ARM64_T8140 Exclaves boot status: BOOTED_EXCLAVEKIT Fileset Kernelcache UUID: A8F02DC88564CCE03DA847AD0490DC4C Kernel UUID: 6F5E696D-EDA7-3AA0-91DC-24B13CF58148 Boot session UUID: 3CD68A8E-AE49-400E-856D-8FADE5EDA6F6 iBoot version: mBoot-18000.120.36 iBoot Stage 2 version: mBoot-18000.120.36 secure boot?: YES roots installed: 0 Paniclog version: 15 Debug Header address: 0xfffffe0027b8d000 Debug Header entry count: 3 TXM load address: 0xfffffe0037ae8000 TXM UUID: F0C1A57F-CE44-3DF4-9E86-0CFF02D7C00D Debug Header kernelcache load address: 0xfffffe0047ae8000 Debug Header kernelcache UUID: A8F02DC8-8564-CCE0-3DA8-47AD0490DC4C SPTM load address: 0xfffffe0027ae8000 SPTM UUID: C84A0523-AF4D-3597-92F6-0E00C05F8444 KernelCache slide: 0x0000000040ae4000 KernelCache base: 0xfffffe0047ae8000 Kernel slide: 0x0000000040aec000 Kernel text base: 0xfffffe0047af0000 Kernel text exec slide: 0x0000000044e64000 Kernel text exec base: 0xfffffe004be68000 mach_absolute_time: 0x784b3a110 Epoch Time: sec usec Boot : 0x6a40bc40 0x000e856c Sleep : 0x6a40e957 0x00055678 Wake : 0x6a40eb98 0x000459ac Calendar: 0x6a40eba2 0x000e0b73 Zone info: Zone map: 0xfffffe1270000000 - 0xfffffe3870000000 . VM : 0xfffffe1270000000 - 0xfffffe183c000000 . RO : 0xfffffe183c000000 - 0xfffffe1ad6000000 . GEN0 : 0xfffffe1ad6000000 - 0xfffffe20a2000000 . GEN1 : 0xfffffe20a2000000 - 0xfffffe266e000000 . GEN2 : 0xfffffe266e000000 - 0xfffffe2c3a000000 . GEN3 : 0xfffffe2c3a000000 - 0xfffffe3206000000 . DATA : 0xfffffe3206000000 - 0xfffffe3870000000 Metadata: 0xfffffe1164010000 - 0xfffffe116d810000 Bitmaps : 0xfffffe116d810000 - 0xfffffe116ee08000 Extra : 0 - 0 CORE 0 [EACC0] recently retired instr at 0x0000000000000000 CORE 1 [EACC0] recently retired instr at 0x0000000000000000 CORE 2 [EACC0] recently retired instr at 0x0000000000000000 CORE 3 [EACC0] recently retired instr at 0x0000000000000000 CORE 4 [PACC1] recently retired instr at 0x0000000000000000 CORE 5 [PACC1] recently retired instr at 0x0000000000000000 TPIDRx_ELy = {1: 0xfffffe2b3862b738 0: 0x0000000000000003 0ro: 0x000000016fd870e0 } CORE 0: PC=0xfffffe004c06c684, LR=0xfffffe004c06c680, FP=0xfffffe7617c3be40 CORE 1: PC=0xfffffe004c06c684, LR=0xfffffe004c06c680, FP=0xfffffe7617cbbe40 CORE 2: PC=0xfffffe004c06c684, LR=0xfffffe004c06c680, FP=0xfffffe7617a7be40 CORE 3 is the one that panicked. Check the full backtrace for details. CORE 4: PC=0xfffffe004bf27af8, LR=0xfffffe004bf27af8, FP=0xfffffe7617cebee0 CORE 5: PC=0xfffffe004bf27af8, LR=0xfffffe004bf27af8, FP=0xfffffe7616babee0 Compressor Info: 4% of compressed pages limit (OK) and 2% of segments limit (OK) with 0 swapfiles and OK swap space Panicked task 0xfffffe1fa1f85c88: 238 pages, 4 threads: pid 343: watchdogd Panicked thread: 0xfffffe2b3862b738, backtrace: 0xfffffe761737b2c0, tid: 22525 lr: 0xfffffe004bebf650 fp: 0xfffffe761737b360 lr: 0xfffffe004c0688b0 fp: 0xfffffe761737b3d0 lr: 0xfffffe004c066844 fp: 0xfffffe761737b490 lr: 0xfffffe004be6de9c fp: 0xfffffe761737b4a0 lr: 0xfffffe004bebf998 fp: 0xfffffe761737b840 lr: 0xfffffe004bebef90 fp: 0xfffffe761737ba10 lr: 0xfffffe004c7e2608 fp: 0xfffffe761737ba30 lr: 0xfffffe004c6a2be8 fp: 0xfffffe761737bb20 lr: 0xfffffe004c0218a0 fp: 0xfffffe761737bb50 lr: 0xfffffe004beef8b0 fp: 0xfffffe761737bbf0 lr: 0xfffffe004be9a3e8 fp: 0xfffffe761737bc50 lr: 0xfffffe004beb0108 fp: 0xfffffe761737bca0 lr: 0xfffffe004beb068c fp: 0xfffffe761737bda0 lr: 0xfffffe004c060cec fp: 0xfffffe761737be50 lr: 0xfffffe004c066e00 fp: 0xfffffe761737bf10 lr: 0xfffffe004be6de9c fp: 0xfffffe761737bf20 lr: 0x0000000187505c34 fp: 0x0000000000000000 last started kext at 4198789793: com.apple.filesystems.smbfs 6.0.1 (addr 0xfffffe004872c460, size 113379) loaded kexts: (skipped, see boot kernelcache) ** Exclaves panic stackshot not found ** Stackshot Succeeded ** Bytes Traced 437787 (Uncompressed 995728) **

Hi all, I'm building an iOS app extension using ExtensionKit that works exclusively with its containing host app, presenting UI via EXHostViewController. I'd like the extension to have read-only access to the host's task for process introspection purposes. I'm aware this would almost certainly require a special entitlement. I know get-task-allow and the debugger entitlement exist, but those aren't shippable to the App Store. I'm looking for something that could realistically be distributed to end users. My questions: Does an entitlement exist (or is one planned) that would grant an extension limited, read-only access to its host's task—given the extension is already tightly coupled to the host? If not, is this something Apple would consider adding? The use case is an extension that needs to inspect host process state without the ability to modify it. Is there a path to request such an entitlement through the provisioning profile process, or is this fundamentally off the table for App Store distribution? It seems like a reasonable trust boundary given the extension already lives inside the host's app bundle, but I understand the security implications. Any insight appreciated. Thanks!

panic(cpu 6 caller 0xfffffe00408d5cc8): "AMCC0 DCS GROUP 0 CHANNEL 0 AMPH_AIC_IRQ_EN_FLD error: INTSTS 0x00000002" @AppleH16GFamilyPlatformErrorHandler.cpp:4284 Debugger message: panic Memory ID: 0xff OS release type: User OS version: 25F80 Kernel version: Darwin Kernel Version 25.5.0: Mon Apr 27 20:41:26 PDT 2026; root:xnu-12377.121.6~2/RELEASE_ARM64_T8132 Fileset Kernelcache UUID: 810ED0581F8496D5014005FD8C299E58 Kernel UUID: 4FEB3A7D-D020-3910-B7AF-232C78D32651 Boot session UUID: BD3ADC9E-8793-494E-A0D9-2764E76D7F6E iBoot version: mBoot-18000.120.36 iBoot Stage 2 version: mBoot-18000.120.36 secure boot?: YES roots installed: 0 Paniclog version: 15 Debug Header address: 0xfffffe001de0d000 Debug Header entry count: 3 TXM load address: 0xfffffe002dd68000 TXM UUID: F0C1A57F-CE44-3DF4-9E86-0CFF02D7C00D Debug Header kernelcache load address: 0xfffffe003dd68000 Debug Header kernelcache UUID: 810ED058-1F84-96D5-0140-05FD8C299E58 SPTM load address: 0xfffffe001dd68000 SPTM UUID: BF0FEC4B-5AEA-35B8-BF85-518497A9C1C5 KernelCache slide: 0x0000000036d64000 KernelCache base: 0xfffffe003dd68000 Kernel slide: 0x0000000036d6c000 Kernel text base: 0xfffffe003dd70000 Kernel text exec slide: 0x000000003b488000 Kernel text exec base: 0xfffffe004248c000 mach_absolute_time: 0x1832dfe2d Epoch Time: sec usec Boot : 0x6a3ef98d 0x000c2461 Sleep : 0x6a3efa94 0x00069c13 Wake : 0x00000000 0x00000000 Calendar: 0x6a3efa96 0x000a335d Zone info: Zone map: 0xfffffe100c000000 - 0xfffffe360c000000 . VM : 0xfffffe100c000000 - 0xfffffe15d8000000 . RO : 0xfffffe15d8000000 - 0xfffffe1872000000 . GEN0 : 0xfffffe1872000000 - 0xfffffe1e3e000000 . GEN1 : 0xfffffe1e3e000000 - 0xfffffe240a000000 . GEN2 : 0xfffffe240a000000 - 0xfffffe29d6000000 . GEN3 : 0xfffffe29d6000000 - 0xfffffe2fa2000000 . DATA : 0xfffffe2fa2000000 - 0xfffffe360c000000 Metadata: 0xfffffe9654010000 - 0xfffffe965d810000 Bitmaps : 0xfffffe965d810000 - 0xfffffe96605b0000 Extra : 0 - 0 CORE 0 [EACC0] recently retired instr at 0x0000000000000000 CORE 1 [EACC0] recently retired instr at 0x0000000000000000 CORE 2 [EACC0] recently retired instr at 0x0000000000000000 CORE 3 [EACC0] recently retired instr at 0x0000000000000000 CORE 4 [EACC0] recently retired instr at 0x0000000000000000 CORE 5 [EACC0] recently retired instr at 0x0000000000000000 CORE 6 [PACC1] recently retired instr at 0x0000000000000000 CORE 7 [PACC1] recently retired instr at 0x0000000000000000 CORE 8 [PACC1] recently retired instr at 0x0000000000000000 CORE 9 [PACC1] recently retired instr at 0x0000000000000000 TPIDRx_ELy = {1: 0xfffffe2ea1fe8900 0: 0x0000000000000006 0ro: 0x0000000000000000 } CORE 0: PC=0x0000000000000000, LR=0x0000000000000000, FP=0x0000000000000000 CORE 1: PC=0x0000000000000000, LR=0x0000000000000000, FP=0x0000000000000000 CORE 2: PC=0x0000000000000000, LR=0x0000000000000000, FP=0x0000000000000000 CORE 3: PC=0x0000000000000000, LR=0x0000000000000000, FP=0x0000000000000000 CORE 4: PC=0x0000000000000000, LR=0x0000000000000000, FP=0x0000000000000000 CORE 5: PC=0x0000000000000000, LR=0x0000000000000000, FP=0x0000000000000000 CORE 6 is the one that panicked. Check the full backtrace for details. CORE 7: PC=0x0000000000000000, LR=0x0000000000000000, FP=0x0000000000000000 CORE 8: PC=0x0000000000000000, LR=0x0000000000000000, FP=0x0000000000000000 CORE 9: PC=0x0000000000000000, LR=0x0000000000000000, FP=0x0000000000000000 Compressor Info: 0% of compressed pages limit (OK) and 0% of segments limit (OK) with 0 swapfiles and OK swap space Panicked task 0xfffffe28d5fa3960: 0 pages, 634 threads: pid 0: kernel_task Panicked thread: 0xfffffe2ea1fe8900, backtrace: 0xfffffea9d5fdabd0, tid: 102 lr: 0xfffffe00424e2194 fp: 0xfffffea9d5fdac70 lr: 0xfffffe00426602a0 fp: 0xfffffea9d5fdace0 lr: 0xfffffe004265e234 fp: 0xfffffea9d5fdada0 lr: 0xfffffe0042491e9c fp: 0xfffffea9d5fdadb0 lr: 0xfffffe00424e24a4 fp: 0xfffffea9d5fdb2d0 lr: 0xfffffe0042dd35c4 fp: 0xfffffea9d5fdb2f0 lr: 0xfffffe00408d5cc8 fp: 0xfffffea9d5fdb630 lr: 0xfffffe00408d6090 fp: 0xfffffea9d5fdbef0 lr: 0xfffffe0042ccd0b0 fp: 0xfffffea9d5fdbf30 lr: 0xfffffe00402f16e4 fp: 0xfffffea9d5fdbfc0 lr: 0xfffffe0042661a50 fp: 0xfffffea9d5fdbfe0 lr: 0xfffffe0042491f40 fp: 0xfffffea9d5fdbff0 lr: 0xfffffe0042506714 fp: 0xfffffe5be553bee0 lr: 0xfffffe0042506670 fp: 0xfffffe5be553bf20 lr: 0xfffffe0042492b6c fp: 0x0000000000000000 Kernel Extensions in backtrace: com.apple.driver.AppleT8132(1.0)[47D903D9-8F8C-3E63-BD11-57EC7038EE44]@0xfffffe00408c9310->0xfffffe00408d96a3 dependency: com.apple.driver.AppleARMPlatform(1.0.2)[85AF824B-70B0-3C11-BE82-F90BD4A57DC8]@0xfffffe003f7d7d30->0xfffffe003f82b0f3 dependency: com.apple.driver.AppleEverestErrorHandler(1)[656D28F2-FD94-3B53-AD95-C1DEE28140D2]@0xfffffe003ff78f60->0xfffffe003ff79ebb dependency: com.apple.iokit.IOReportFamily(47)[B53BE23F-34ED-35B3-9E6C-12B7BECC2267]@0xfffffe00418563a0->0xfffffe0041858eeb com.apple.driver.AppleInterruptControllerV3(1.0d1)[17E37838-AA51-37A2-B605-871825C22626]@0xfffffe00402ee730->0xfffffe00402f2ba3 dependency: com.apple.driver.AppleARMPlatform(1.0.2)[85AF824B-70B0-3C11-BE82-F90BD4A57DC8]@0xfffffe003f7d7d30->0xfffffe003f82b0f3 last started kext at 717088811: com.apple.filesystems.autofs 3.0 (addr 0xfffffe003ea21780, size 5927) loaded kexts: (skipped, see boot kernelcache) ** Stackshot Succeeded ** Bytes Traced 474581 (Uncompressed 1135664) **

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've seen a number of similar posts from other network system extension developers reporting kernel panics on M5 devices in macOS. These kernel panics occur when network system extensions are enabled and are not observed on earlier mac platforms or versions of macOS. Reference: https://developer.apple.com/forums/thread/821372 In this post, it appears like Apple is aware of a problem as noted by Kevin Elliott in versions of macOS. Do we know if there is any way to work around this problem (short of not enabling a network filter) until a fix is available?

Installing ZFSFSKit.appex ? /Library/ExtensionKit/Extensions/ Substituting real Mach-O (libtool wrapper ? .libs/ZFSFSKit) Installing zfs.fs ? /Library/Filesystems/ mount_zfs: Mach-O 64-bit executable arm64 Done. Signing (before pluginkit, so it sees a valid signature)... Re-signing /Library/ExtensionKit/Extensions/ZFSFSKit.appex ad-hoc (no identity). Note: requires amfi_get_out_of_my_way=1 in boot-args. Team ID: ADHOC /Library/ExtensionKit/Extensions/ZFSFSKit.appex: replacing existing signature Done. Signature: Identifier=org.openzfsonosx.filesystems.zfs.fsext Signature=adhoc TeamIdentifier=not set Entitlements: <?xml version="1.0" encoding="UTF-8"?><!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "https://www.apple.com/DTDs/PropertyList-1.0.dtd"><plist version="1.0"><dict><key>com.apple.application-identifier</key><string>ADHOC.org.openzfsonosx.filesystems.zfs.fsext</string><key>com.apple.developer.fskit.fsmodule</key><true/><key>com.apple.developer.team-identifier</key><string>ADHOC</string><key>com.apple.security.app-sandbox</key><true/></dict></plist> Registering with pluginkit... pluginkit -a done. Restarting fskitd... # sudo pluginkit -v -m -p com.apple.fskit.fsmodule + org.openzfsonosx.filesystems.zfs.fsext((null)) 6A12A41280FB-4190-B957-FA94DC89BB1E 2026-05-29 01:17:58 +0000 /Library/ExtensionKit/Extensions/ZFSFSKit.appex # sudo mkdir /Volumes/tank # sudo mount -F -t zfs /dev/disk4 /Volumes/tank # ls -la /Volumes/tank total 3 drwxr-xr-x 3 lundman staff 4 May 29 09:21 . drwxr-xr-x 4 root wheel 128 May 29 10:18 .. -rw-r--r-- 1 lundman staff 11 May 29 09:21 file.txt drwxr-xr-x 2 lundman staff 2 May 29 09:21 HelloWorld # cat /Volumes/tank/file.txt HelloWorld Even though FSKit isn't quite ready, I built a proof-of-concept FSKit extension to understand what the migration path looks like. This post shares what we got working, specific technical findings that weren't documented, and the gaps we hit that would need Apple's attention for a production implementation. Luckily, OpenZFS already compiles in userland for the "zdb" utility so not much work was required on that side. There were certain amount of desperation applied when we came across hurdles, so possibly some assumptions we formed are not correct. (We didn't go back and confirm the problem after it started working).

Hello Everyone, Like probably several other Enterprise customers and more, we have been bitten by a bug with regards to VPN and Endpoint Security and the new M5 / M5 Pro SoCs shipping in the latest MacBook devices. I have raised the following feedback IDFB22753954 (which itself references an internal issue I believe, if we need to mark it as a dupe: 172793638 ). The technical sequence leading to the crash is as follows I believe: The macOS system process neagent successfully initializes the GlobalProtect network extension. The GP Network extension transitions from an 'inactive' state to a 'running' state. As network traffic begins flowing through the extension, a critical flaw in the macOS kernel's memory allocation (specifically related to the Apple Network Extension framework) is triggered. This memory management failure at the kernel level results in a kernel panic at an unpredictable point during packet processing. Because this is a core operating system vulnerability, any third-party application or security solution that leverages Apple's Network Extension framework is susceptible to these crashes. This has been confirmed across multiple vendors within the cybersecurity industry from what I understand. Crashes_M5Pro_1.txt Thank you in advance for your help! Kind Regards, Goffredo

We see a major delay for the first open("disk.img", O_RDONLY); we perform. If it helps, we use clonefile() to copy a sparsed image. if (-1 == (fd = open(path, (mode & O_ACCMODE) | O_CLOEXEC))) return -1; 1791 Thread_1071327 DispatchQueue_1: com.apple.main-thread (serial) 1791 start (in dyld) + 6076 [0x189f72b98] 1791 main (in anka_image) + 20 [0x102171bb8] 1791 clp_main (in libpolicy.dylib) + 2120 [0x102a49eac] 1790 process_info (in anka_image) + 68 [0x1021723f4] + 1790 vdsk_open (in libvdsk.dylib) + 92 [0x1021d90e8] + 1790 vdsk_open_native (in libvdsk.dylib) + 164 [0x1021d91c0] + 1790 open (in libsystem_kernel.dylib) + 64 [0x18a2dd6a4] + 1790 __open (in libsystem_kernel.dylib) + 8 [0x18a2d2678] What advice do you have for diagnosing what is causing the first open to do this? Is this some sort of security scan happening? Indexing?

I have a custom-developed USB NCM device for a networking use case. My device is successfully enumerated by macOS at the USB layer, and it issues a USB SET_INTERFACE(altsetting = 1) to enable the NCM layer, but sometimes (about 50% of the time), the Mac then issues a USB SET_INTERFACE(altsetting = 0), which disables the interface. It never issues a SET_INTERFACE(altsetting = 1) command to re-enable it. In Network settings, the device just stays in the "Disconnected" state forever. For context, the NCM specification says that all NCM devices must have two "alternate settings" at the USB interface level. Altsetting 0 is the default "disabled" startup state where no data endpoints are enabled, and altsetting 1 is the "enabled" state where data IN/OUT endpoints are enabled and packets can be transferred. The NCM spec also says that SET_INTERFACE(altsetting=0) can be used by the host to 'reset' the NCM layer of the device back to known settings. I suspect this is what the Mac is trying to do, though it only does it 50% of the time. The remainder of the time, the device stays in altsetting 1 and traffic works just fine. My question is, how can I get to the bottom of why the Mac is sometimes sending the SET_INTERFACE(altsetting=0) command or, if this behavior is usual, why is it not then re-enabling using SET_INTERFACE(altsetting=1) ? "log stream --info --debug" shows no information on this, and the NCM driver is a closed-source kernel extension so I have no visibility of what it's doing and why. I've sniffed the USB bus using a packet analyzer and can't see anything odd there (no timing issues or dropped packets etc). Any tips would be appreciated. I'm on Tahoe 26.4.1. I really don't want to develop a custom driver for this device and would prefer to operate with the native NCM driver.

As part of the OpenJDK testing we run several regression tests, including for Java SE networking APIs. These APIs ultimately end up calling BSD socket functions. On macos, starting macos 26, including on recent 26.2 version, we have started seeing some unexplained but consistent exception from one of these BSD socket APIs. We receive a "ENOBUFS" errno (No buffer space available) when trying to construct a socket(). These exact same tests continue to pass on many other older versions of macos (including 15.7.x). After looking into this more, we have been able to narrow this down to a very trivial C code which is as follows (also attached): #include <stdio.h> #include <sys/socket.h> #include <string.h> #include <unistd.h> #include <sys/errno.h> static int create_socket(const int attempt_number) { const int fd = socket(AF_INET6, SOCK_STREAM, 0); if (fd < 0) { fprintf(stderr, "socket creation failed on attempt %d," " due to: %s\n", attempt_number, strerror(errno)); return fd; } return fd; } int main() { const unsigned int num_times = 250000; for (unsigned int i = 1; i <= num_times; i++) { const int fd = create_socket(i); if (fd < 0) { return -1; } close(fd); } fprintf(stderr, "successfully created and closed %d sockets\n", num_times); } The code very trivially creates a socket() and close()s it. It does this repeatedly in a loop for a certain number of iterations. Compiling this as: clang sockbufspaceerr.c -o sockbufspaceerr.o and running it as: ./sockbufspaceerr.o consistently generates an error as follows on macos 26.x: socket creation failed on attempt 160995, due to: No buffer space available The iteration number on which the socket() creation fails varies, but the issue does reproduce. Running the same on older versions of macos doesn't reproduce the issue and the program terminates normally after those many iterations. Looking at the xnu source that is made available for each macos release here https://opensource.apple.com/releases/, I see that for macos 26.x there have been changes in this kernel code and there appears to be some kind of memory accountability code introduced in this code path. However, looking at the reproducer/application code in question, I believe it uses the right set of functions to both create as well as release the resources, so I can't see why this should cause the above error in macos 26.x. Does this look like some issue that needs attention in the macos kernel and should I report it through feedback assitant tool?

Hi, I am developing instant snapshot backup solution for macOS using Endpoint Security. We have stumbled upon a Kernel Panic when using "fclonefileat" API. We are catching a kernel panic on customer machines when attempting to clone the file during ES sync callback: panic(cpu 0 caller 0xfffffe002c495508): "apfs_io_lock_exclusive : Recursive exclusive lock attempt" @fs_utils.c:435 I have symbolized the backtrace to know it is related to clone operation with the following backtrace: apfs_io_lock_exclusive apfs_clone_internal apfs_vnop_clonefile I made a minimal repro that boils down to the following operations: apfs_crash_stress - launch thread to do rsrc writes static void *rsrc_write_worker(void *arg) { int id = (int)(long)arg; char buf[8192]; long n = 0; fill_pattern(buf, sizeof(buf), 'W' + id); while (n < ITERATION_LIMIT) { int file_idx = n % NUM_SOURCE_FILES; int fd = open(g_src_rsrc[file_idx], O_WRONLY | O_CREAT, 0644); if (fd >= 0) { off_t off = ((n * 4096) % RSRC_DATA_SIZE); pwrite(fd, buf, sizeof(buf), off); if ((n & 0x7) == 0) fsync(fd); close(fd); } else { setxattr(g_src[file_idx], "com.apple.ResourceFork", buf, sizeof(buf), 0, 0); } n++; } printf("[rsrc_wr_%d] done (%ld ops)\n", id, n); return NULL; } apfs_crash_es - simple ES client that is cloning the file (error checking omitted for brevity) static std::string volfsPath(uint64_t devId, uint64_t vnodeId) { return "/.vol/" + std::to_string(devId) + "/" + std::to_string(vnodeId); } static void cloneAndScheduleDelete(const std::string& sourcePath, dispatch_queue_t queue, uint64_t devId, uint64_t vnodeId) { struct stat st; if (stat(sourcePath.c_str(), &st) != 0 || !S_ISREG(st.st_mode)) return; int srcFd = open(sourcePath.c_str(), O_RDONLY); const char* cloneDir = "/Users/admin/Downloads/_clone"; mkdir(cloneDir, 0755); const char* filename = strrchr(sourcePath.c_str(), '/'); filename = filename ? filename + 1 : sourcePath.c_str(); std::string cloneFilename = std::string(filename) + ".clone." + std::to_string(time(nullptr)) + "." + std::to_string(getpid()); std::string clonePath = std::string(cloneDir) + "/" + cloneFilename; fclonefileat(srcFd, AT_FDCWD, clonePath.c_str(), 0); { dispatch_after(dispatch_time(DISPATCH_TIME_NOW, 1 * NSEC_PER_SEC), queue, ^{ if (unlink(clonePath.c_str()) == 0) { LOG("Deleted clone: %s", clonePath.c_str()); } else { LOG("Failed to delete clone: %s", clonePath.c_str()); } }); } close(srcFd); } static const es_file_t* file(const es_message_t* msg) { switch (msg->event_type) { case ES_EVENT_TYPE_AUTH_OPEN: return msg->event.open.file; case ES_EVENT_TYPE_AUTH_EXEC: return msg->event.exec.target->executable; case ES_EVENT_TYPE_AUTH_RENAME: return msg->event.rename.source; } return nullptr; } int main(void) { es_client_t* cli; auto ret = es_new_client(&cli, ^(es_client_t* client, const es_message_t * msgc) { if (msgc->process->is_es_client) { es_mute_process(client, &msgc->process->audit_token); return respond(client, msgc, true); } dispatch_async(esQueue, ^{ bool shouldClone = false; if (msgc->event_type == ES_EVENT_TYPE_AUTH_OPEN) { auto& ev = msgc->event.open; if (ev.fflag & (FWRITE | O_RDWR | O_WRONLY | O_TRUNC | O_APPEND)) { shouldClone = true; } } else if (msgc->event_type == ES_EVENT_TYPE_AUTH_UNLINK || msgc->event_type == ES_EVENT_TYPE_AUTH_RENAME) { shouldClone = true; } if (shouldClone) { if (auto f = ::file(msgc)) cloneAndScheduleDelete(f->path.data, cloneQueue, f->stat.st_dev, f->stat.st_ino); } respond(client, msgc, true); }); }); LOG("es_new_client -> %d", ret); es_event_type_t events[] = { ES_EVENT_TYPE_AUTH_OPEN, ES_EVENT_TYPE_AUTH_EXEC, ES_EVENT_TYPE_AUTH_RENAME, ES_EVENT_TYPE_AUTH_UNLINK, }; es_subscribe(cli, events, sizeof(events) / sizeof(*events)); } Create 2 terminal sessions and run the following commands: % sudo ./apfs_crash_es % sudo ./apfs_crash_stress ~/Downloads/test/ Machine will very quickly panic due to APFS deadlock. I expect that no userspace syscall should be able to cause kernel panic. It looks like a bug in APFS implementation and requires fix on XNU/kext side. We were able to reproduce this issue on macOS 26.3.1/15.6.1 on Intel/ARM machines. Here is the panic string: panic_string.txt Source code without XCode project: apfs_crash_es.cpp apfs_crash_stress.cpp Full XCode project + full panic is available at https://www.icloud.com/iclouddrive/0f215KkZffPOTLpETPo-LdaXw#apfs%5Fcrash%5Fes

The most recent KDK for MacOS Sequoia that appears in the Downloads is for MacOS 15.5 (24F74), but the current version of MacOS Sequoia is 15.6 (24G84) and 15.7 (24G207) is in RC. Is there an ETA for the KDKs for 15.6 (24G84) and 15.7 (24G207) to be made available to download? Many thanks for any help.

Hi, I'm posting a boot crash here. Environment Hardware: Macbook M5 Pro OS Version: macOS 26.3.1 (25D2128) and matching version of KDK from official apple download page Kernel Version: Darwin Kernel Version 25.3.0 Reproducibility: Consistent Here is my panic log --- I truncated one field "SOCDNandContainer" as the original log is too long to post, hitting the size limit. I followed a blog post to boot the development kernel as the ReadMe file from KDK only contains instructions for Intel Macs. https://jaitechwriteups.blogspot.com/2025/10/boot-custom-macos-kernel-on-macos-apple.html I've tried a few 26.2 KDKs before 26.3.1 public launch, and they all showed same errors (26.1 and 26.0 KDKs don't have any development kernel for T8142 chip). Also, I own two fresh M5 Pro, and it is consistent across the machines. The highlight is panic(cpu 8 caller 0xfffffe0050e18010): [Exclaves] $JgOSLogServerComponent.RedactedLogServer.init(logServerNotific:OSLogServerComponent\/OSLogServerComponent_Swift.swift:815: Fatal error: invalid rawValue for TightbeamComponents.RedactedLogSer at PC ... Is this a genuine bug or am I following a wrong guide to boot the development kernel? I don't think the blog is wrong because I'm able to boot the "release" kernel included in the KDK on the same M5 Pro, and the "development" kernel on M4 Mac Mini, using the same routine. Just to be clear, I'm not compiling XNU myself, but am using the ones included in the kit.

Hi everyone, I am developing a benchmarking tool to measure memory latency (L1/L2/DRAM) on Apple Silicon. I am currently using Xcode Instruments (CPU Counters) to validate my results. In my latest run for a 128 MB buffer with random access, Instruments shows: Latency (cycles): ~259 cycles (derived from LDST_UNIT_OLD_L1D_CACHE_MISS / L1D_CACHE_MISS_LD). Manual Timer Result: ~80 ns. To correlate these two values, I need the exact CPU Frequency (GHz) at the time of the sample. My Questions: Is there a recommended way to programmatically fetch the current frequency of the Performance cores (p-cores) during a benchmark run? Does Apple provide a "nominal" frequency value for M-series chips that we should use for cycle-to-nanosecond conversions? In Instruments, is there a hidden counter or "Average Frequency" metric that I can enable to avoid manual math? Hardware/Software Environment: Tool: Instruments 26.3+ (CPU Counters Template). Chip: A19, iPhone 17 pro. OS: 26.3.

I have noticed that there are no new kdk builds since mid December Is everything ok at apple I am aware of NXUs but the kernel version has changed much since then