EXC_BAD_ACCESS in drawHierarchy(in:afterScreenUpdates:) on iOS 26.3.1+ — IOSurface CIF10 decompression crash

We're experiencing an EXC_BAD_ACCESS (SIGSEGV) crash in UIView.drawHierarchy(in:afterScreenUpdates: false) that occurs only on iOS 26.3.1 and later. It does not reproduce on iOS 26.3.0 or earlier.

Crash Stack

Thread 0 (Main Thread) — EXC_BAD_ACCESS KERN_INVALID_ADDRESS

0  libvDSP.dylib               vConvert_XRGB2101010ToARGB8888_vec
1  ImageIO                     IIOIOSurfaceWrapper_CIF10::CopyImageBlockSetWithOptions
2  ImageIO                     IIOImageProviderInfo::CopyImageBlockSetWithOptions
3  ImageIO                     CGImageReadGetBytesAtOffset
4  CoreGraphics                CGAccessSessionGetBytes
5  CoreGraphics                img_data_lock
6  CoreGraphics                CGSImageDataLock
7  CoreGraphics                ripc_AcquireImage
8  CoreGraphics                ripc_DrawImage
9  CoreGraphics                CGContextDrawImage
10 UIKitCore                   -[UIView(Rendering) drawHierarchy:afterScreenUpdates:]

The crash occurs during 10-bit CIF10 → 8-bit ARGB8888 pixel conversion when the IOSurface backing a UIImageView in the view hierarchy is deallocated mid-render.

How to Reproduce

1. Display a scrollable list with multiple UIImageViews loaded via an async image library
2. Call drawHierarchy(in: bounds, afterScreenUpdates: false) on visible cells periodically
3. Scroll to trigger image recycling
4. Crash occurs sporadically — more likely under memory pressure or rapid image recycling

What We've Tried

Both UIKit off-screen rendering approaches crash on iOS 26.3.1:

iOS Version Correlation

• iOS 26.3.0 and earlier: No crash
• iOS 26.3.1 (23D8133)+: Crash occurs (~5 events per 7 days)

We suspect the ImageIO security patches in iOS 26.3 (CVE-2026-20675, CVE-2026-20634) may have changed IOSurface lifecycle timing, exposing a race condition between drawHierarchy's composited buffer read and asynchronous IOSurface reclamation by the OS.

Crash Data

We sampled 3 crash events:

• Event 1 (iOS 26.3.1): 71 MB free memory — memory pressure
• Event 2 (iOS 26.3.1): 88 MB free memory — memory pressure
• Event 3 (iOS 26.3.2): 768 MB free memory — NOT memory pressure

Event 3 shows this isn't purely a low-memory issue. The IOSurface can be reclaimed even with ample free memory, likely due to async image recycling.

Question

Is this a known regression in iOS 26.3.1? Is there a safe way to snapshot a view hierarchy containing IOSurface-backed images without risking EXC_BAD_ACCESS? Should drawHierarchy gracefully handle the case where an IOSurface backing store is reclaimed during the render?

Any guidance or workarounds would be appreciated. We've also filed this as Feedback (will update with FB number after submission).