Dead Pixel Detected: A Security Assessment of Apple's Graphics Subsystem

Dead Pixel Detected: A Security Assessment of Apple's Graphics Subsystem

Speakers: Yu Wang, Co-founder & CEO, Cyberserval; presented by Weiteng Chen, Microsoft Research Redmond

Conference: Black Hat USA 2025 — August 6-7, 2025, Mandalay Bay, Las Vegas

YouTube: https://www.youtube.com/watch?v=JYmh7gCoIFo

Reading Time: ~8 minutes

Type: Briefing

TL;DR

Yu Wang's systematic audit of Apple's graphics subsystem uncovered kernel vulnerabilities across every layer of the stack — from legacy Intel and AMD GPU plug-in extensions to Apple Silicon's AGX GPU module, the high-profile IOMobileFrameBuffer component, and the Display Coprocessor (DCP) firmware. Multiple CVEs were issued, several bugs were initially misclassified by Apple as denial-of-service rather than exploitable memory corruption, and at least one vulnerability affecting the latest iOS and macOS releases remains unpatched as of the talk's delivery.

Introduction

Apple's graphics subsystem spans a deep and multi-layered architecture: user-mode applications interact with runtime frameworks (Metal, OpenGL, Vulkan), which talk to kernel-mode plug-in drivers, which in turn communicate with GPU hardware, and — on Apple Silicon — with a separate Display Coprocessor (DCP) running its own firmware. The sheer complexity of this stack, combined with limited debug symbols and sparse documentation from Apple, has kept it relatively underexplored in security research.

That gap is closing. This briefing, based on work by Yu Wang (Cyberserval), presented at Black Hat USA 2025 by his colleague Weiteng Chen (Microsoft Research) after Wang was unable to attend due to a visa issue, presents a comprehensive assessment of vulnerabilities found at each layer of the graphics subsystem. The conclusion is blunt: the graphics subsystem is a productive target for zero-day research, Apple's vulnerability descriptions frequently understate severity, and firmware-level attack surfaces are effectively an open frontier.

Layer One: Legacy GPU Kernel Extensions (Intel and AMD)

▶ Watch: Overview and Legacy GPU Bugs (02:00)

The research begins with kernel extension modules responsible for communicating with Intel and AMD GPUs — plug-in drivers that ship with macOS to support older hardware. Three vulnerabilities were discovered in this portion of the stack.

The first, in the AMD GPU support kernel extension, arose from insufficient sanitization of user-supplied input. An offset value stored in register RCX — fully controllable by the user — was used to compute a kernel memory address, enabling arbitrary memory write. The magic values visible in the crash debugger output confirmed complete attacker control.

A second bug in the display metrics module produced both out-of-bounds read and write conditions through similar lack of input validation. A third vulnerability in the Apple Intel ME client controller module involved type confusion: a function expected to allocate a 0x40-byte object could be directed to treat that object as a larger structure, triggering out-of-bounds memory access. Reverse engineering this module was especially labor-intensive because Apple does not publish a kernel debug kit for it.

A newer vulnerability was also found in the Apple Intel graphics module via the invalidContentKey function, which accepted a user-controlled index stored in register RCX — again a magic number confirming full attacker control — and used it directly for a memory write operation.

Layer Two: Apple Silicon GPU (AGX) Bugs

▶ Watch: Apple Silicon GPU Vulnerabilities (06:00)

The AGX GPU module — Apple's own GPU design used in all modern Apple Silicon devices — introduced a different class of vulnerability. Reverse engineering the user-kernel interface exposed the createNotificationQueue function, which accepts two critical parameters without adequate sanitization: the number of queue entries and the size of each entry. Providing malformed values to this function triggers out-of-bounds access.

A more significant bug was found in the GPU's resource allocation function. The initial PoC submitted to Apple triggered a kernel crash but was classified as a local denial-of-service. The researchers found that with more careful crafting — specifically by manipulating registers X8 and X9 to point to valid kernel addresses — the same bug becomes a controllable out-of-bounds write primitive. Apple's initial patch addressed only the narrow corner case described in the PoC, and the team found a second input capable of bypassing that patch, forcing Apple to patch the same vulnerability a second time.

This episode illustrates a broader concern raised during the talk: Apple's security update descriptions routinely mischaracterize vulnerability severity. A bug that becomes an out-of-bounds write with careful exploitation should not be published as a denial-of-service. The security community has already reached consensus that local denial-of-service does not qualify for CVE assignment — yet the original description for this bug implied DoS, misleading other researchers about the bug's true impact.

Layer Three: IOMobileFrameBuffer — A High-Profile Attack Surface

▶ Watch: IOMobileFrameBuffer History and New Bug (12:02)

IOMobileFrameBuffer (IOMFB) is among the most consequential kernel components in Apple's ecosystem. Because it is accessible from web content processes, vulnerabilities here enable browser sandbox escape — making them highly attractive to advanced threat actors. Public records document sixteen kernel vulnerabilities from IOMFB over twenty years, of which four were exploited by APT groups, two appeared in iOS jailbreak tools, and one was featured in a security competition.

A code refactoring event around 2020 introduced a wave of new bugs, creating a notable surge in CVEs for the following two years. The researchers identify this as a cautionary lesson: reckless refactoring can introduce catastrophic security regressions, and the security community typically takes roughly six months to catch up to newly introduced attack surfaces.

The new IOMFB vulnerability disclosed here is a signed/unsigned integer confusion bug. A function accepting a single signed integer parameter performs a range check against a maximum value, but then uses the parameter as an unsigned integer for array indexing. A negative input bypasses the upper-bound check and triggers out-of-bounds access. What makes this finding notable is that the vulnerability can be triggered directly from user space without any special entitlements or permissions. Comparing the fixes Apple shipped across different macOS versions, the team found two entirely different remediation approaches, suggesting separate engineering teams own different macOS releases of the same module.

Layer Four: Display Coprocessor Firmware

▶ Watch: DCP Firmware Fuzzing and Findings (18:02)

Beginning in the second half of 2021, Apple began migrating key IOMFB functionality down one layer — into firmware running on the Display Coprocessor (DCP), a separate processor on Apple Silicon chips. From a security engineering standpoint, this creates a form of defense-in-depth: user mode can no longer directly trigger the relocated code paths. From an offensive standpoint, the code still exists and is reachable if an attacker understands the inter-processor communication protocol.

The research team performed extensive reverse engineering of both the DCP architecture and its RTBuddy IPC mechanism — the channel through which the Application Processor and DCP exchange data. Using this understanding, they built a custom fuzzer targeting the DCP communication interface.

Fuzzing produced a large volume of crashes. The crash logs, read directly from debugger memory via the RTBuddy mechanism, provided full call stacks and detailed context. Among the findings was a previously unknown video interface that had received almost no prior security attention — reachable by user-mode applications without any permissions or entitlements. At least one vulnerability found through this fuzzing was confirmed by Apple to affect the latest versions of both iOS and macOS, with multiple general-purpose registers (R2, R8, and even the LR link register) directly controllable by an attacker. Details remain under embargo pending a patch.

Apple's Vulnerability Description Problem

A recurring theme throughout the talk is the mismatch between how Apple describes vulnerabilities in its security updates and the actual severity those bugs can achieve. Researchers outside the company — reading Apple's terse security advisories — have published analyses incorrectly concluding that certain bugs are unexploitable, partly because Apple labeled them "denial of service" or attributed them to null pointer dereferences without clarifying the underlying root cause.

The team engaged Apple directly on this issue and received assurances that the description practice would be improved. For the security research community, the practical implication is clear: Apple's single-line vulnerability descriptions should not be treated as authoritative assessments of exploitability.

Notable Quotes

"If you don't remember anything I talk about today, the only takeaway you should remember is that the graphics subsystem in Apple is a good target to start with if you're looking for zero-day bugs."

— Weiteng Chen (on behalf of Yu Wang) ▶ 00:00

"Such description leads to confusion. We found that some other researchers got confused by the descriptions from Apple's updates, and they have even written some articles explaining why null pointer dereference cannot be exploited."

— Weiteng Chen ▶ 08:00

"Reckless refactoring can sometimes cause significant security implications to the system. Even in the era of AI and vibe coding, there's no guarantee they will always produce correct code."

— Weiteng Chen ▶ 24:03

"The code is still there, they just hide them from the layer above. But if you know how they communicate between each layer, you can still find a way to trigger those buggy code."

— Weiteng Chen ▶ 26:03

Key Takeaways

• Every layer of Apple's graphics stack has been found vulnerable — from legacy Intel/AMD kernel extensions to the AGX GPU module, IOMobileFrameBuffer, and DCP firmware. No component should be assumed secure by obscurity.
• Apple's security update descriptions routinely understate severity. A bug described as "denial of service" may in fact be a controllable out-of-bounds write. Researchers should verify root causes independently rather than relying on Apple's published descriptions.
• Code refactoring is a major bug-introduction event. The IOMFB surge following the 2020 refactoring illustrates that security review must be a mandatory gate before large-scale code changes are shipped.
• Moving code to firmware is a mitigation, not a fix. Apple's strategy of relocating IOMFB functionality to DCP firmware raises the bar but does not eliminate the attack surface — the code remains reachable via the RTBuddy IPC interface.
• DCP firmware is an underexplored frontier. User-mode applications can directly invoke DCP interfaces without entitlements; custom fuzzing immediately produced crashes including a confirmed vulnerability in the latest iOS and macOS releases.

Slides

Slides are available as a PDF: "Dead Pixel Detected: A Security Assessment of Apple's Graphics Subsystem" by Yu Wang and Weiteng Chen.