Kernel panic "m->m_flags & M_PKTHDR" in uipc_mbuf.c on SMB clients over 10 GbE (macOS 26)

Question

Created 6h

Replies 1

Boosts 0

Participants 1

We have a group of Macs that mount SMB shares over 10 GbE with jumbo frames (MTU 9000). Since late June, they have been kernel panicking several times a day with the same assertion:

panic(cpu N caller ...): assertion failed: m->m_flags & M_PKTHDR, file: .../xnu/bsd/kern/uipc_mbuf.c, line: 4839 @uipc_socket.c:8260
Panicked thread: dlil_input_en0
Last started kext: com.apple.filesystems.smbfs 6.0.1

Environment

Clients: Mac Studio (M1 Max and M1 Ultra) and Mac Pro (2019, Intel with T2), using the built-in 10GBASE-T at MTU 9000
macOS 26.5.1 (25F80), 26.6.2 (25G83) and 26.7 (25G229); it panics on all three
Servers: Samba-based NAS, SMB 3.1.1, signing on, encryption off
Filed as FB24912731

What we've found

It still panics with our third-party EDR fully uninstalled.
The Mac that panics needs an active SMB session. A Mac left on the network without a share mounted stayed up through several events that took down the others.
Panics are often simultaneous across machines: two to six Macs, with different hardware and different macOS builds, within the same minute.
It doesn't need sustained heavy throughput. Some panics came within minutes of reconnecting, during light editing.
Setting kern.skywalk.flowswitch.rx_agg_tcp_host=0 did not help.
The switch and server links stay up, and spanning tree doesn't change during these events. Only the Macs' ports drop.
In one server-side capture, the client stopped sending within about 0.2 ms of receiving a READ response made of 8948-byte frames. That fits the panicked thread being dlil_input.

Two existing threads look related

Kernel panic using Vagrant synced folders via NFS beginning with macOS 15.4 (FB17853906). A DTS reply there said the issue is in kernel mbuf management and that SMB "is very likely to experience a similar panic."
Incorrect packet handling in SMBClient MacOS 26, which describes a race in SMBClient under heavy load above about 10 Gbps.

Questions

Is this the same underlying issue as FB17853906, and is a fix planned for macOS 26? Our 2019 Mac Pros can't move to a later major release.
Is there a known workaround, such as a sysctl, an nsmb.conf option, or a change to MTU or offload settings?
Is there logging or a diagnostic we can leave enabled to capture more state at panic time? We can't reproduce this on demand, but between several machines we see it multiple times a day.

We can provide full panic reports, sysdiagnoses, and packet captures from both client and server sides.

Answer 1

sethg1 OP

34m

Update: likely trigger found. A switch-port mirror of an affected Mac caught a panic. The Mac was idle, with no SMB traffic for about 10 minutes. The last frames it received, about 1 second before its link dropped, were a burst of about 60 mDNS packets in 25 ms from a Windows 11 PC on the same MTU 9000 network, many of them jumbo-sized (up to 4468 bytes). They came from Windows Delivery Optimization local peer discovery (_dosvc._tcp.local), which seemed to be stuck in a name-conflict loop.

Across about 24 hours of capture, every panic lined up with mDNS traffic from that PC, and when it went quiet for 5½ hours, nothing panicked. The Macs still need an active SMB session to panic, so the mDNS traffic seems to be the trigger and the SMB session the precondition.

Mitigation: on the Windows PC, set Delivery Optimization to Simple mode (DODownloadMode = 99 under HKLM\SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimization), which stopped the announcements. We're watching to confirm the panics stop. Details added to FB24912731.

If you're seeing this panic on a jumbo-frame network with Windows 10/11 PCs on it, this is worth checking.