The iPhone kernel checked the arithmetic, then read past the array

An ordinary sandboxed app on my test iPhone could make kernel display code read beyond an array and fault while using a value I had supplied. The app needed no special entitlement for the affected operation. The device records supported more than an unexplained crash: they showed the selected value reaching the kernel’s working state. They did not show kernel data coming back to the app.

The code had a check that looked reassuring. It checked whether the arithmetic used to locate an array entry overflowed. What it failed to check was whether that entry existed. A neighboring operation accessed the same array and performed both checks. The distinction was sitting in the implementation, close enough to make the omission particularly irritating.

My report covers that missing boundary check in IOMobileFrameBuffer, now listed as CVE-2026-65398. Apple published fixes in its September 14, 2026 releases. The live results described here came from an iPhone 16 Pro running iOS 27.0 beta 4. I also examined the Mac path, where an earlier gate stopped the operation before it reached the vulnerable code.

Apple’s IOMobileFrameBuffer advisory for CVE-2026-65398

The calculation could fit while the entry did not

To find an array entry, software calculates its location from the start of the array and the size of each entry. An overflow check asks whether that calculation fits in the computer’s arithmetic. A bounds check asks whether the selected entry belongs to the array. A calculation can pass the first test and still point beyond the last entry.

The neighboring operation used the same array and helper, but performed both checks. The affected operation omitted the boundary check, allowing the kernel to treat memory beyond the array as a legitimate entry and use what it found there. The implementation already contained the right example; this operation failed to follow it.

What the crash records established

The useful evidence was in the relationship between the test input and the kernel state at failure. A processor keeps temporary working values in registers. The report showed a selected value appearing in that state when the affected kernel operation faulted, with the crash location and surrounding processing matching the code analysis.

I did not rely on one value appearing once. The successful captures spanned different boots and changing values. A control deliberately used a different value and produced the corresponding result. That supported the conclusion that the register contents followed the supplied data, rather than merely coinciding with an existing value on the device.

The records still needed to be associated with the correct run. Some logs were retrieved while the test was running, before the later panic record existed. That gave those captures a stronger connection to the input recorded for the run. I also excluded duplicate files and unrelated failures from the successful-capture evidence. They did not become independent confirmations simply because they occupied separate places in a directory.

The result was not equally reliable on every attempt. It depended on which memory the invalid access reached, and those conditions varied. The report records misses and other faults alongside successful captures. A crash outside the condition being measured could help explain the test’s behavior, but it did not establish the same claim as a capture with the expected kernel state.

A separate, smaller set of results concerned the address the kernel tried to read. Those captures showed faulting accesses at the selected addresses across different boots. Their association with the corresponding run logs was weaker than the strongest register-control evidence, and the procedure was less repeatable. I kept those results separate instead of borrowing the confidence of the larger set.

Most importantly, a faulting attempt to read an address is not the same as returning the contents of that address to the application. The report did not recover kernel data through this path. The kernel attempted the access and faulted. That distinction changes what an attacker has actually demonstrated, even if both descriptions can be made to sound like “reading kernel memory.”

The Mac refused before reaching the bug

The Mac code contained the defective operation, but the Mac I tested rejected the request at an earlier gate. I could open the service; I could not reach the affected operation. The runtime refusal matched the code for that gate. I therefore made no macOS exploitability claim and did not test every Mac model or display configuration. The broader platform list below is Apple’s published fix coverage; my device-proven result was on the iPhone.

The limits were in the failure too

On the iPhone, I obtained kernel faults with selected working values and faulting accesses. I did not obtain code execution or control of the instruction pointer that determines what executes next, and I did not defeat pointer authentication. The writes considered in the report could store only fixed zero values under additional constraints; they were not a general way to write chosen content. These device tests did not evaluate memory-tagging protection.

Apple describes CVE-2026-65398 as an out-of-bounds access issue that could let an app terminate the system unexpectedly or corrupt kernel memory, addressed by improved bounds checking. The neighboring operation in my report already showed what the vulnerable access lacked: a decision about whether the requested entry belonged to the array.

Apple’s published impact and bounds-checking fix

The September fixes and shared credit

Apple lists the fix in these September 14, 2026 releases:

• iOS 27 and iPadOS 27

• macOS Golden Gate 27

• tvOS 27

• watchOS 27

• visionOS 27

Use the current supported update offered for your device. The releases above identify where Apple first published this fix; they are not a recommendation to install an older system.

Apple credits Chris Bailey - Short Circuit, Mustafa Calap (@ordinal0, dbg.re), David Strnadel, and Meta Red Team X - Nik Tsytsarkin. Thank you to the other credited researchers and to Apple’s security and engineering teams for addressing the issue.

The five September Apple CVEs credited to Short Circuit

Apple’s advisories checked October 26, 2026. The technical account comes from my final research report; the linked vendor entries establish the published impact, credit and release coverage.