This appears to be an issue on macOS 12.2.1 (21D62) too. Just received some crash logs from a customer that seems like it is the same crash signature (this is one of four different crashes that occured over the course of a week or so. Every crash has the same this basic signature): Date/Time: 2024-03-25 11:37:15.6659 -0400 OS Version: macOS 12.2.1 (21D62) Report Version: 12 Anonymous UUID: 11FA4AA4-0231-994D-2404-EA518B20693B Time Awake Since Boot: 860000 seconds System Integrity Protection: enabled Crashed Thread: 91 Dispatch queue: com.apple.CFNetwork.LoaderQ Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000058 Exception Codes: 0x0000000000000001, 0x0000000000000058 Exception Note: EXC_CORPSE_NOTIFY Termination Reason: Namespace SIGNAL, Code 11 Segmentation fault: 11 Terminating Process: exc handler [87810] ... Thread 91 Crashed:: Dispatch queue: com.apple.CFNetwork.LoaderQ 0 libdispatch.dylib 0x19ed97ce0 _dispatch_source_set_runloop_timer_4CF + 32 1 CFNetwork 0x1a3d997dc 0x1a3bb1000 + 2000860 2 CFNetwork 0x1a3d997dc 0x1a3bb1000 + 2000860 3 CFNetwork 0x1a3d99e9c 0x1a3bb1000 + 2002588 4 CFNetwork 0x1a3bcba88 0x1a3bb1000 + 109192 5 CFNetwork 0x1a3c4df40 0x1a3bb1000 + 642880 6 libdispatch.dylib 0x19ed80e60 _dispatch_call_block_and_release + 32 7 libdispatch.dylib 0x19ed82bac _dispatch_client_callout + 20 8 libdispatch.dylib 0x19ed8a330 _dispatch_lane_serial_drain + 672 9 libdispatch.dylib 0x19ed8aed8 _dispatch_lane_invoke + 444 10 libdispatch.dylib 0x19ed8c1c0 _dispatch_workloop_invoke + 1796 11 libdispatch.dylib 0x19ed95708 _dispatch_workloop_worker_thread + 656 12 libsystem_pthread.dylib 0x19ef3d304 _pthread_wqthread + 288 13 libsystem_pthread.dylib 0x19ef3c018 start_wqthread + 8 Thread 91 crashed with ARM Thread State (64-bit): x0: 0x0000000000000000 x1: 0x000012ec4f6a5421 x2: 0xffffffffffffffff x3: 0x000000003b9aca00 x4: 0x0000000000000000 x5: 0x0000000000000017 x6: 0x0000000000000000 x7: 0x0000000000000000 x8: 0x000000003b9aca00 x9: 0x800012ec4f6a5421 x10: 0x0000000055d4a800 x11: 0x0000000039387000 x12: 0x00000000016e3600 x13: 0x000000000003fca8 x14: 0x00000000ee269000 x15: 0x00000001f85f5540 x16: 0x000000019ed97cc0 x17: 0x00000001f9a44938 x18: 0x0000000000000000 x19: 0x0000000000000000 x20: 0x000060000064ee60 x21: 0x000060000003d210 x22: 0x0000000000000000 x23: 0x0000000000000000 x24: 0x0000000000000000 x25: 0x0000000000000000 x26: 0x0000000000000114 x27: 0x000060000187c140 x28: 0x000060000187c140 fp: 0x000000016d8ee660 lr: 0x15290001a3d997dc sp: 0x000000016d8ee620 pc: 0x000000019ed97ce0 cpsr: 0x20001000 far: 0x0000000000000058 esr: 0x92000006 (Data Abort) byte read Translation fault It seems to somewhat be related to multiple threads initiating HTTP requests at once, as the crash seems to correlate to a log from our process which prints out some info about a HTTP request getting squashed (ie Mar 25 11:37:15 --- last message repeated 1 time ---) Unfortunately I haven't found a reliable way to reproduce this yet. However, after looking into this a bit further (and not knowing which version of libdispatch is included in macOS 12.2.1 (21D62)), from looking at the source for a version of libdispatch, it does seem to point to a null ptr deref is causing the crash (assuming x0: 0x0000000000000000 is getting passed in as first argument): void _dispatch_source_set_runloop_timer_4CF(dispatch_source_t ds, dispatch_time_t start, uint64_t interval, uint64_t leeway) { // Don't serialize through the source queue for CF timers <rdar://13833190> _dispatch_source_set_timer(ds, start, interval, leeway, false); } DISPATCH_ALWAYS_INLINE static inline void _dispatch_source_set_timer(dispatch_source_t ds, dispatch_time_t start, uint64_t interval, uint64_t leeway, bool source_sync) { if (slowpath(!ds->ds_is_timer) || slowpath(ds_timer(ds->ds_refs).flags & DISPATCH_TIMER_INTERVAL)) { DISPATCH_CLIENT_CRASH(ds, "Attempt to set timer on a non-timer source"); } ... } Id guess the offset of ds_is_timer in the dispatch_source_t struct happens to be 0x58, which is causing the KERN_INVALID_ADDRESS at 0x0000000000000058.

Oof, serves me right for not doing my own research. That was the time change info I was relayed by one of the support staff that I trust to get their details correct. :facepalm: But as far as I can tell from that wiki page, you are correct, being stuck on CST is the correct behavior.