Hi all,
I've run into a kernel deadlock issue involving content filter + VPN system/network extension on macOS 26, and would really appreciate any insights.
A user reported that their mac is occasionally assigened a 169.254.0.0/16 address and can't reach any website after connecting Wi-Fi. Disabling our content filter restores network connectivity immediately.
They're running the following software on the mac:
- macOS 26 (issue reproduced on 25C56 and 25F71)
- NEFilterDataProvider-based content filter (our extension)
- VPN network extension
A spindump taken while the system had lost network connectivity shows the content filter's process stuck while delivering an "allow" verdict to the kernel. All subsequent flow decisions for the extensions are blocked behind it, which would explain why new DHCP request can't complete and the interface stays on a self-assigned address.
Based on the "last ran" and timestamp in the spindump, the underlying deadlock appears to have occurred while the computer wasn't connected to any Wi-Fi network, so there was no visible symptom at the time. The user only noticed something was wrong once they tried to reconnect and saw the bad IP address; they did not realize the content filter was already stuck.
This issue may be identified by searching for keyword "sofreelastref" in the spindump (see comment below).
Has anyone else seen a content filter + VPN hang like this on macOS 26? Any guidance or pointers would be greatly appreciated. Thanks in advance!
For Developer Technical Support staffs: FB23720745
Shay
If you’re ever able to reproduce this, please grab a sysdiagnose log and attach it to your bug report. Likewise, if you’re working with a customer who’s seeing this, please ask them to do the same. If they don’t want to share a sysdiagnose log with you, they can file their own bug, attach the log to that, and then pass their bug number along.
That spindump is… well… interesting. There’s a lot of other stuff going on at the time the log was taken, and some of it is quite worrying.
Let’s start with the 34 instances of the networksetup, all running under Rosetta. Is that your doing? Because they all seem to have been launched by one of the 9 instances of f_-s____m-s_____e_d____n-a____ [1], which are also running under Rosetta.
Oh, and then there’s the 63 instances of bash O-:
And there’s a total of 7 system extensions running: 5 from you, 2 from another developer, and 1 from yet another developer. And at least 3 of those are Endpoint Security sysexen, and any one of those has the capability to bork the entire system.
My advice here is for you to work with this customer to try to simplify their configuration in order to isolate the problem. As a first step, I recommend that you get the ES sysexen out of the mix, because it’s ridiculously easy for such products to create problems like this. If you can still reproduce the problem with only the NE sysexen, then at least you know that this is a networking problem.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] Redacting the exact name, for pretty obvious reasons.