I am using NETransparentProxyProvider to transparently proxy port 80 443 Normal processing within the initial period of time (BOOL) handleNewFlow: (NEAppProxyFlow *) fw However, after running for a period of time, this callback will not be triggered again, and the system's network will be disconnected Stop network extension and the system's network returns to normal OS 11.4 M1 OS 12.1 Intel

OS Version: macOS 13.6.3 (22G436) Code Type: ARM64 We recently observed that the system extension process CPU based on networkextension (data-filter firewall) has been 99% busy for a period of time. We try to deauthorize data-filter so that the firewall stops working and the NEFilterDataProvider object is released. However, the system extension process CPU usage is always 99% busy. Then I used Instruments-CPU Counters to observe that a thread (thread id: 0x2abf9b) has been busy, but no useful backtrace information was captured. Through the sample command, I caught the backtrace and found that the busy process (thread id: 2801563 == 0x2abf9b) is in this state. 35 Thread_1336407 DispatchQueue_442: NEFilterExtensionProviderContext queue (serial) + 35 start_wqthread (in libsystem_pthread.dylib) + 8 [0x1a1afad94] + 35 _pthread_wqthread (in libsystem_pthread.dylib) + 288 [0x1a1afc074] + 35 _dispatch_workloop_worker_thread (in libdispatch.dylib) + 648 [0x1a1963244] + 35 _dispatch_lane_invoke (in libdispatch.dylib) + 384 [0x1a19585f8] + 35 _dispatch_lane_serial_drain (in libdispatch.dylib) + 372 [0x1a1957960] + 35 _dispatch_source_invoke (in libdispatch.dylib) + 1176 [0x1a1966ce0] + 35 _dispatch_source_cancel_callout (in libdispatch.dylib) + 204 [0x1a1967890] + 35 _dispatch_continuation_pop (in libdispatch.dylib) + 504 [0x1a1953884] + 35 _dispatch_client_callout (in libdispatch.dylib) + 20 [0x1a1950400] + 35 _dispatch_call_block_and_release (in libdispatch.dylib) + 32 [0x1a194e874] + 35 __75-[NEFilterDataExtensionProviderContext setupSocketSourceWithControlSocket:]_block_invoke (in NetworkExtension) + 112 [0x1b1e0dd74] + 35 close (in libsystem_kernel.dylib) + 8 [0x1a1ac0ac0] note: the picture screenshot and the text description backtrace are from different machines, but the problem is the same. This seems to be a newly introduced bug in the network extension? This problem did not occur for a long time between 10.15 and 10.12.