Post

Replies

Boosts

Views

Activity

Reply to macOS 26 – NSSound/CoreAudio causes SIGILL crash in caulk allocator
@DTS Engineer I have performed a diff analysis of caulk.framework and AudioToolbox across macOS 26.3.2, 26.4, 26.5, and 26.6 Beta 1 using the ipsw tool, analyzing the disassembled outputs guided by LLM analysis pipeline. I would appreciate it if Apple engineering could review and verify if the following mechanism explains the regression: ** LLM Report** The resulting analysis presents a highly compelling hypothesis pointing to a strict alignment assertion mismatch under Rosetta 2 translation rather than standard heap corruption. I would appreciate it if Apple engineering could review and verify if the following mechanism explains the regression: The Alignment Assertion: In caulk::alloc::page_allocator::allocate, there is a boundary assertion check: assert(alignment <= vm_page_size) If this invariant is violated, the allocator executes a ud2 compiler trap, triggering SIGILL (ILL_ILLOPC). Proposed macOS 26.4+ Regression Model: In macOS 26.3.2 (caulk v214.0), the x86_64 slice requested standard alignments (e.g. 16 bytes or 4 KB) satisfying the assertion boundary under Rosetta’s emulated 4 KB page size (vm_page_size = 4096). However, in macOS 26.4+ (caulk v214.501), binary analysis indicates the recompiled translated x86_64 slice of AudioToolbox was built using native ARM64 templates, enforcing a hard-coded 16 KB alignment template: caching_page_allocator<16384ul> When page_allocator::allocate(size, 16384) is called under translation, it checks against the emulated vm_page_size (4096), resulting in a logical contradiction (16384 <= 4096 => False). The ASLR/Intermittency Hypothesis: Under Rosetta translation, the kernel allocates page blocks aligned to 4 KB boundaries. By pure probability, 25% of the time, the returned 4 KB-aligned pointer from mmap/vm_allocate coincidentally aligns on a 16 KB boundary. The assertion passes and the app runs normally without crashing. 75% of the time, the pointer is only 4 KB-aligned (but not 16 KB-aligned). The assertion fails immediately, triggering the ud2 instruction at maybe_create_free_node + 119. Assembly Capture from macOS 26.4+ movq 0x305314e9(%rip), %rax ; Load pointer to _vm_page_size from GOT movq (%rax), %rax ; Dereference vm_page_size (returns 4096 under Rosetta 2) cmpq %rax, %rdx ; Compare requested Alignment (%rdx) with vm_page_size (%rax) ja 0x7ff80fb22c5b ; Jump to trap if Alignment > vm_page_size ... 0x7ff80fb22c6a: ud2 ; Trigger Undefined Instruction Exception (SIGILL)
Topic: Media Technologies SubTopic: Audio Tags:
2w
Reply to macOS 26 – NSSound/CoreAudio causes SIGILL crash in caulk allocator
@DTS Engineer I have performed a diff analysis of caulk.framework and AudioToolbox across macOS 26.3.2, 26.4, 26.5, and 26.6 Beta 1 using the ipsw tool, analyzing the disassembled outputs guided by LLM analysis pipeline. I would appreciate it if Apple engineering could review and verify if the following mechanism explains the regression: ** LLM Report** The resulting analysis presents a highly compelling hypothesis pointing to a strict alignment assertion mismatch under Rosetta 2 translation rather than standard heap corruption. I would appreciate it if Apple engineering could review and verify if the following mechanism explains the regression: The Alignment Assertion: In caulk::alloc::page_allocator::allocate, there is a boundary assertion check: assert(alignment <= vm_page_size) If this invariant is violated, the allocator executes a ud2 compiler trap, triggering SIGILL (ILL_ILLOPC). Proposed macOS 26.4+ Regression Model: In macOS 26.3.2 (caulk v214.0), the x86_64 slice requested standard alignments (e.g. 16 bytes or 4 KB) satisfying the assertion boundary under Rosetta’s emulated 4 KB page size (vm_page_size = 4096). However, in macOS 26.4+ (caulk v214.501), binary analysis indicates the recompiled translated x86_64 slice of AudioToolbox was built using native ARM64 templates, enforcing a hard-coded 16 KB alignment template: caching_page_allocator<16384ul> When page_allocator::allocate(size, 16384) is called under translation, it checks against the emulated vm_page_size (4096), resulting in a logical contradiction (16384 <= 4096 => False). The ASLR/Intermittency Hypothesis: Under Rosetta translation, the kernel allocates page blocks aligned to 4 KB boundaries. By pure probability, 25% of the time, the returned 4 KB-aligned pointer from mmap/vm_allocate coincidentally aligns on a 16 KB boundary. The assertion passes and the app runs normally without crashing. 75% of the time, the pointer is only 4 KB-aligned (but not 16 KB-aligned). The assertion fails immediately, triggering the ud2 instruction at maybe_create_free_node + 119. Assembly Capture from macOS 26.4+ movq 0x305314e9(%rip), %rax ; Load pointer to _vm_page_size from GOT movq (%rax), %rax ; Dereference vm_page_size (returns 4096 under Rosetta 2) cmpq %rax, %rdx ; Compare requested Alignment (%rdx) with vm_page_size (%rax) ja 0x7ff80fb22c5b ; Jump to trap if Alignment > vm_page_size ... 0x7ff80fb22c6a: ud2 ; Trigger Undefined Instruction Exception (SIGILL)
Topic: Media Technologies SubTopic: Audio Tags:
Replies
Boosts
Views
Activity
2w