the problem of high CPU usage of network extension (filter-data)

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.