CoreMedia “Removed the Vulnerable Code,” Tracing Three Deleted AV1 and Lens Functions

Abstract. CVE-2026-64752 is Apple’s CoreMedia memory-corruption bug for which “a maliciously crafted image may lead to arbitrary code execution,” fixed “by removing the vulnerable code.”1 A removal fix leaves no bounds check to diff, so this note looks for code that exists on an affected build and is gone on a fixed one. Three CoreMedia functions fit on exact iPhone17,3 files: _parse_frame_hdr (9,880 bytes) and _av1_bytealign_get_bits, both called only from _FigAV1Bridge_parseOBU, and _writeCameraSystemLensAtom (8,552 bytes), called only from the video-extended-usage atom writer. All three exist in iOS 27 beta 24A5390f and are absent in 24A5408d and in macOS 27.0. _FigAV1Bridge_parseOBU stays and shrinks by 1,792 bytes. The same names appear and disappear across iOS 26.x betas but never ship in a 26.x release, which fits Apple listing this CVE only on the “27” pages. Scope: this is Patch-observed symbol and size evidence plus a reachability hypothesis (AV1 configuration OBUs in an AVIF image). No image was shown to reach the deleted code, no input was built, and nothing was run against it.

1. Introduction

Apple credits Nik Tsytsarkin.1 The fix sentence is the unusual part. “Improved bounds checking” leaves a new compare in the fixed binary; “removing the vulnerable code” leaves a hole. So the questions here are: what disappeared between a build that had the bug and one that did not; which of those deletions is plausibly reachable from an image; and why the advisory lists only the 27-series releases.

Layout: advisory (§2); what the public diff can and cannot say (§3); exact binaries (§4); the three deleted functions and the parser that kept them (§5); release history and the advisory list (§6); the image entry hypothesis (§7); what was not shown (§8); record (§9).

Evidence labels used throughout.

• Apple-confirmed — text on an Apple security-content page.
• Patch-lead — public ipsw-diffs output used only to narrow the search.
• Patch-observed — checked in IDA 9.4 on an exact, hashed CoreMedia.
• Hypothesis — an inference that has not been tested.

2. Where Apple lists it

Every other CoreMedia memory bug on these pages is also fixed in the 26.7 / 15.8 updates. This one is not. Either the 26.x line never had the code, or Apple chose not to backport. §6 shows the first is what the binaries say.

3. The public diff, and its false friends

Patch-lead. ipsw-diffs at commit 5887e5ca27256558f8c4d9c675abcdf0f8a42bbb has exactly one large CoreMedia change in the iOS 27 beta series, 27_0_24A5390f_vs_27_0_24A5408d (iPhone18,1 restores):5

Most of the 2,314 missing functions are FigNote, Fig trace, and tailspin instrumentation — a release-build strip, not a security fix. A shrinking binary is not evidence by itself. The macOS pair 27_0_26A5388g_vs_27_0_26A5421a shows the same shrink, and also marks FigSignalErrorAt, FigSignalErrorAt2, and FigSignalErrorAt3 as deleted. On the exact macOS 27.0 file those three are still exported, so that row of the diff is wrong for the shipped binary.

After 24A5408d, CoreMedia stays near 0x20b000 of text through the release; no later step removes a comparable block.

4. Exact binaries

The iOS files are iPhone17,3 extracts of the same build numbers as the diff, not the iPhone18,1 slices it names.

24A5390f has 18,123 functions in IDA (image base 0x18ee7c000). One database per UUID; the same probe script (SHA-256 99ccb1f8…d0df) ran on each.

5. What was removed

Patch-observed. Symbols in 24A5390f that are absent by name in both 24A5408d and 26A428, after excluding instrumentation:

5.1 The AV1 pair

_FigAV1Bridge_parseOBU survives on all three builds but shrinks:

On 24A5390f it receives a byte buffer and length, rejects length <= 2 and NULL outputs, and walks OBUs:

0x18f0835dc  CMP   X1, #2
0x18f0835e0  B.LS  reject                       ; buffer too short
0x18f0835e4  MOV   X28, X0
0x18f0835e8  CBZ   X0, reject
0x18f0835ec  CBZ   X3, reject
0x18f0835f4  CBZ   X4, reject
0x18f0835fc  CBZ   X5, reject
0x18f083614  ADD   X8, X28, X1                  ; end = buf + len

On that build it calls _parse_frame_hdr from one site (judging by the name, for frame-header OBUs; the dispatch condition was not decoded), and calls _av1_bytealign_get_bits from three. _parse_frame_hdr opens by consulting fields deep in a sequence-header state ([X27,#0x3B0], #0x3C0, #0x3C8, #0x3D8) and writing frame state into the output structure ([X19,#0xE8], #0x104, #0x114). The byte-align helper clears its reader state and returns 0 when fewer than 8 bits are pending; with 8 or more pending it returns 0xFFFFCE58 (−12712):

0x18eee1fcc  LDR   W8, [X0,#0x10]               ; bits left
0x18eee1fd0  CMP   W8, #8
0x18eee1fd4  B.CC  ok                           ; < 8 bits → W0 = 0
...
0x18eee1fe8  MOV   W0, #0xFFFFCE58
0x18eee1ff4  STR   WZR, [X19,#0x10]
0x18eee1ff8  STR   XZR, [X19,#8]

A 9.9 KB AV1 frame-header parser is large, full of conditionally present syntax elements, and writes into fixed-size state indexed by stream fields (tile counts, segmentation, loop-filter deltas, reference indices). That is a classic place for memory corruption, and removing it while keeping the OBU walker is consistent with “removing the vulnerable code.” This is an inference; no specific write was identified in it (§8).

Callers of _FigAV1Bridge_parseOBU on 24A5390f:

These are metadata and configuration paths: CoreMedia parses OBUs to describe a stream, not to decode pixels (dav1d or hardware does that).

5.2 The lens-atom writer

_writeCameraSystemLensAtom is a writer, not a parser. It opens an atom writer, begins an atom whose type is computed as 0x6C656674 + 0x7FF = 0x6C656E73 ('lens'), and reads kCMFormatDescriptionExtension_CameraCalibrationDataLensCollection from the format description:

0x18f0940e8 BL   _FigAtomWriterInitWithParent
0x18f0940f0 MOV  W19, #0x6C656674        ; 'left'
0x18f0940fc ADD  W1, W19, #0x7FF         ; 'lens'
0x18f094104 BL   _FigAtomWriterBeginAtom
0x18f094114 ADRL X8, _kCMFormatDescriptionExtension_CameraCalibrationDataLensCollection
0x18f094128 BL   _CMFormatDescriptionGetExtension

It serializes camera-calibration lens data (the per-eye metadata that spatial video carries) into a QuickTime atom. Its input is a format-description extension that would come from a parsed file, so a malformed lens collection could in principle drive it. It is a weaker fit for “processing a crafted image” than the AV1 pair, but it is just as deleted.

6. Why only the 27 releases

Lab-observed / Patch-observed absence. The lab VM’s iOS 26.6.2 / 23G90 cache matches the IPSW cache (UUID F216D3F4-…). Its CoreMedia has _FigAV1Bridge_parseOBU (0x197df0d04) and _FigAV1Bridge_parseav1c (0x197df0b78), nm finds none of the three names, and the next symbol after parseOBU is 0x2cd8 away — shorter than the 24A5390f body that called _parse_frame_hdr. The only _parse_frame_hdr string in the guest’s symbol file sits beside _dav1d_parse_obus, _parse_seq_hdr, and _parse_tile_hdr: that is dav1d’s own static function, not CoreMedia. iOS 26.4 / 23E246 is the same story.

Patch-lead. In ipsw-diffs the three CoreMedia names come and go across the 26.x betas:

That pattern looks like in-development code that rides along in betas and is stripped before each release. If the vulnerable code only ever shipped in betas, there was nothing to fix in 26.7 or 15.8, which matches the advisory list in §2. It also means the “affected” builds for this CVE are betas, and the fix is the release build not containing the code. This is the most economical reading of the evidence; Apple has not stated it.

7. How an image could reach it

Hypothesis. An AVIF still image is an HEIF container whose image items carry an av1C property, and av1C can embed configuration OBUs (sequence header, metadata). A reader that hands av1C to _FigAV1Bridge_parseav1c, or asks CoreMedia for HDR metadata (CLLI, MDCV, HDR10+, Dolby Vision) from it, would put attacker bytes into _FigAV1Bridge_parseOBU, and on 24A5390f that walker would call _parse_frame_hdr for any frame-header OBU it found. “Processing a maliciously crafted image” would then mean an AVIF with a hostile OBU in its configuration record.

What would confirm or kill it, in order:

1. An xref from ImageIO’s AVIF/HEIF reader (or the HDR metadata path) into _FigAV1Bridge_parseav1c / the Copy…FromAV1ConfigurationRecordConfigOBU functions on 24A5390f.
2. Whether parseOBU dispatches frame-header OBUs to _parse_frame_hdr when called from those metadata paths, or only from a sample path.
3. An AVIF whose av1C carries a frame-header OBU, run on a 24A5390f device or VM with a target-side marker on _parse_frame_hdr.

None of these has been done. The 26.x lab VMs cannot help: the code is not in their CoreMedia (§6).

8. What was not shown

• No caller outside CoreMedia was tied to image bytes entering _FigAV1Bridge_parseOBU.
• No specific out-of-bounds or type-confused access was identified inside _parse_frame_hdr; the function was located and sized, not decompiled line by line.
• No input, harness, or campaign exists for this CVE, and no 24A5390f runtime was available.
• The _writeCameraSystemLensAtom deletion was not ranked against the AV1 pair beyond the image-wording argument in §5.2.

No claim here of arbitrary code execution or of a confirmed root cause.

9. Record

[1] Apple, “About the security content of iOS 27 and iPadOS 27,” 14 September 2026. https://support.apple.com/en-us/149034

[2] Apple, “About the security content of macOS Golden Gate 27,” 14 September 2026. https://support.apple.com/en-us/149035

[3] Apple, “About the security content of visionOS 27,” 14 September 2026. https://support.apple.com/en-us/149038

[4] Apple, “About the security content of iOS 26.7 and iPadOS 26.7,” 14 September 2026. https://support.apple.com/en-us/149041

[5] blacktop/ipsw-diffs commit 5887e5ca27256558f8c4d9c675abcdf0f8a42bbb, directory 27_0_24A5390f_vs_27_0_24A5408d. Search aid only. https://github.com/blacktop/ipsw-diffs