Kernel panic m_copym_with_hdrs copy overflow @uipc_mbuf.c:3268 in io.tailscale.ipn.macsys.network-extension, recurring, survives removing a duplicate daemon

## Summary

Recurring kernel panic (identical signature, identical crashing thread's call-chain
shape across occurrences) on macOS, with `io.tailscale.ipn.macsys.network-extension`
present in the process list every time. Not yet resolved by removing an unrelated
duplicate Tailscale daemon that was also present. Filing with the open-source repo
since I don't have a paid plan (self-hosting the control server) and couldn't find
an exact match among the existing open panic reports.

## Environment

- Mac: MacBook Pro, model `Mac16,7` (Apple **M4 Pro** — the `T6041` SoC codename in
the panic log is M4 Pro, not M5; flagging in case that's used to file-match)
- macOS 26.5.2, build 25F84
- Kernel: `Darwin Kernel Version 25.5.0: Tue Jun 9 22:28:34 PDT 2026;
root:xnu-12377.121.10~1/RELEASE_ARM64_T6041`
- Tailscale.app 1.98.8, System Extension ("macsys") variant —
`io.tailscale.ipn.macsys.network-extension` shows `[activated enabled]` in
`systemextensionsctl list`
- Control server: **self-hosted** (not Tailscale SaaS / no paid plan)

## Panic signature (identical in all 3 occurrences)

```
panic(cpu N caller 0x...): m_copym_with_hdrs n 0x... copy overflow @uipc_mbuf.c:3268
```

- Occurrence 1: 2026-08-14 11:00:52
- Occurrence 2: 2026-08-14 11:48:17 (~48 min after #1)
- Occurrence 3: 2026-08-14 22:04:33

Occurrences 2 and 3's crashing-thread backtraces have the **same LR/FP frame-count
and relative structure** (only the ASLR/kernelcache slide differs) — this reads as
one deterministic code path being hit repeatedly, not random memory corruption.

Panicked thread backtrace (occurrence 3, offsets relative to that boot's slide):
```
lr: 0x...321ac fp: 0x...ab40
lr: 0x...3d20 fp: 0x...abb0
lr: 0x...1cb4 fp: 0x...ac70
lr: 0x...1e9c fp: 0x...ac80
lr: 0x...324bc fp: 0x...b1a0
lr: 0x...8354 fp: 0x...b1c0
lr: 0x...4008 fp: 0x...b270 <- panic caller (m_copym_with_hdrs)
lr: 0x...65d8 fp: 0x...b510
lr: 0x...bd50 fp: 0x...b890
lr: 0x...3554 fp: 0x...b8e0
lr: 0x...6eac fp: 0x...b9b0
lr: 0x...4ecc fp: 0x...bcb0
lr: 0x...8708 fp: 0x...bce0
lr: 0x...9424 fp: 0x...bd50
lr: 0x...1fc8 fp: 0x...bd80
lr: 0x...151c fp: 0x...bec0
lr: 0x...2480 fp: 0x...bf20
lr: 0x...2b6c fp: 0x0
```
(No kernel symbols available locally to resolve these further — happy to provide
the full raw `.panic` files if useful.)

## What's been ruled out

Initially suspected a **duplicate Tailscale install**: a Homebrew `tailscaled`
(`/opt/homebrew/Cellar/tailscale/1.92.3`) was running as a crash-looping
per-user LaunchAgent alongside the proper `Tailscale.app` system extension,
both managing `utun` interfaces. Removed the Homebrew daemon and formula
entirely (`brew services stop tailscale && brew uninstall tailscale`),
confirmed removal via `launchctl list` / `brew services list`.

**Panic #3 happened hours later anyway**, with the duplicate confirmed absent
at panic time (verified via `brew services list`, `launchctl list`, and the
panic log's own process list — only the single `io.tailscale.ipn.macsys.*`
jobs present). So the duplicate daemon was a real problem worth fixing, but
not the root cause of this panic.

## Other processes present in all 3 panic logs

`Tailscale`, `io.tailscale.ipn.macsys.network`, and separately Docker Desktop's
networking stack (`com.docker.backend`, `com.docker.vmnetd`,
`com.docker.virtualization`) — Docker is flagged as a lower-confidence,
unconfirmed suspect since nothing in the crashing backtrace points at it
specifically; it's just always running on this machine.

## Possible lead in the open-source code

I don't have access to the macOS System Extension/NetworkExtension wrapper
(per the main repo's README, that part is closed-source), but on the
open-source side, `net/tstun/wrap.go`'s `Wrapper.Write` batches multiple
packets into one vectorized call to the platform `tun.Device.Write(buffs
[][]byte, offset int)`, with the vector size driven by `BatchSize()` /
`conn.IdealBatchSize` (`net/tstun/wrap.go:1229-1283,1483-1492`). That batch
size grows under higher throughput (more packets per `recvmmsg`-style read),
which would line up with #16202 ("kernel panic during high throughput
transfers") also being in this area.

If the macOS wrapper's `Write([][]byte, offset)` implementation has any
off-by-one in vector length vs. actual `NEPacketTunnelFlow` write count,
or a protocol/length bookkeeping mismatch when batch size > 1, that seems
like a plausible way to hand the kernel a malformed/oversized packet chain —
consistent with an `m_copym_with_hdrs` "copy overflow" (a copy where declared
length doesn't match actual data). I can't verify this since I don't have
that source, but it seemed worth flagging for whoever looks at this.

## Related but not-identical existing issues

- #18325 — panic in `skmem_cache_destroy` re: utun teardown, on connect/disconnect toggle
- #16202 — panic during high-throughput transfers
- #19872 — hard hang/black screen on connect (macOS 26.3.1, M1)
- #19016 — "completely broke my Mac Studio"

None of these match the exact `m_copym_with_hdrs @ uipc_mbuf.c:3268` panic string,
so filing as a new report rather than piling onto one of those.

## Impact

This machine is used for production access via Tailscale, so I can't fully
disable Tailscale to isolate/bisect further without losing that access. Happy
to run diagnostics, share the full `.panic` files, or test a debug build if
that would help narrow it down.

Start by reading net/tstun/wrap.go, especially Wrapper.Write, BatchSize(), and conn.IdealBatchSize, then compare the suspected batching path with issue #16202. The macOS NetworkExtension wrapper is closed-source, so use the available panic logs and diagnostics to determine whether vectorized writes can explain the overflow. Done means the batching path is confirmed or ruled out with actionable evidence.

Written by the indexing model from the issue text.