Filing this as a public thread to try to get DTS attention, similar to how thread 821372 (skmem_slab_free_locked double-free) got resolved - accumulated cross-referenced reports there are what got that one fixed in 26.5/26.6.
Panic signature (identical every time): panic(cpu N caller 0x...): m_copym_with_hdrs n 0x... copy overflow @uipc_mbuf.c:3268
My own occurrences: 5 panics over 2 days on a MacBook Pro (Mac16,7 / M4 Pro), macOS 26.5.2 build 25F84, kernel Darwin 25.5.0 (xnu-12377.121.10~1/RELEASE_ARM64_T6041). Filed as Feedback Assistant report FB24343421 (5 panic logs + a full sysdiagnose attached).
Why this looks like a generic kernel bug, not app-specific: I initially suspected a third-party VPN NetworkExtension (Tailscale) since it appeared in the full stackshot of every one of my panics. Ruled that out:
- That NE is a userspace-only component - cannot execute kernel code.
- Two other reporters have hit the identical panic string via completely different, unrelated paths:
- One reproduced it with no VPN/tunnel software running at all (engine stopped, sysext idle) - see FB24333740, cross-referenced at https://github.com/tailscale/tailscale/issues/20864
- Another hit the same panic string on an Intel Mac via a third-party Ethernet kext, no VPN/utun involved at all - https://github.com/SongXiaoXi/AppleIGC/issues/34
So this reproduces through at least 3 independent producer paths (a NetworkExtension, no tunnel software at all, and a third-party Ethernet driver), which points to something generic in the TCP send path (tcp_output -> m_copym_with_hdrs) rather than anything specific to one app or extension.
Known non-workarounds: net.inet.tcp.tso=0 does not avoid the code path (checked against the last public xnu source drop). No sysctl or config change has stopped recurrence for anyone who's tried.
Related public reports: https://github.com/tailscale/tailscale/issues/20864 https://github.com/tailscale/tailscale/issues/20612 https://github.com/SongXiaoXi/AppleIGC/issues/34 FB24333740 (independent Feedback Assistant report, same signature) FB24343421 (mine, this thread)
Still reproducing on the latest public release (26.6.1 / 25G76) per the other reporters. Happy to provide more diagnostics - this is easy to reproduce on my end, roughly every few hours to once a day under normal use.