Update after some additional research: I found an older Apple Developer Forums discussion regarding apparently contradictory sysctl documentation. In that thread, Apple DTS points out that the sysctlbyname page under the Kernel documentation describes the kernel KPI, whereas applications using the user-space BSD sysctlbyname() API should refer to the sysctl(3) man page. The user-space sysctl(3) documentation states that oldlenp is used as the available buffer size on input, and on return contains the amount of data copied. This actually matches what I observed in LLDB: Before: *oldlenp = 4301365248 After: return = 0 *oldlenp = 11 machine = "iPhone18,2" So the change from a very large input value to the actual returned length appears to be expected behavior for the user-space API, rather than an iOS 27 behavioral change. At this point, the remaining question is mainly whether anything changed in iOS/iPadOS 27 (runtime, compiler, stack layout, etc.) that made the pre-existing uninitialized size bug surface more consistently. I have not yet found any other public reports of an iOS/iPadOS 27 regression specifically involving sysctlbyname("hw.machine") and ENOMEM.