AI
Kernel Driver Bugs Across AMD and Intel GPU Modules
Apple’s graphics subsystem spans kernel extensions for Intel, AMD, and Apple’s own silicon. Three bugs found in those third-party GPU modules share the same root cause: functions accepted user-supplied offsets or indices and used them directly to compute kernel memory addresses. The AMD support kext allowed arbitrary memory writes via a fully user-controlled RCX register. The Intel ME client controller had a type confusion bug that allocated a 0x40-byte object but treated it as a larger structure, causing OOB access. Apple provided no kernel debug kit for the display matrix module, making reverse engineering the third bug significantly harder.
Apple GPU Kernel Bugs and CVE Severity Mislabeling
Apple’s AGX GPU kernel module had two OOB write bugs. The first was in createNotificationQueue, which accepted user-supplied entry count and size without bounds checks. They confirmed exploitability with the AGX notification queue OOB PoC crash (07:47). Apple’s advisory labeled it denial-of-service. The team pushed back: local DoS does not qualify for CVE assignment, and a crafted PoC turns this into a write primitive. Apple agreed to update the description. The second bug required two patches: Apple’s first fix only covered the reported case, and a new input bypassed it, shown in the resource allocation bug second patch bypass (11:49).
IOMobileFramebuffer: High-Value Attack Surface
IOMobileFramebuffer is reachable from web content, making it useful for browser sandbox escapes. Public records show 16 kernel CVEs from this module over 20 years. Four were actively exploited by APT groups. Two appeared in iOS jailbreaks. A 2020 code refactoring introduced numerous new bugs, and the CVE count spiked for the next two years. The team also found a signed-versus-unsigned integer mismatch in the related DCP layer: a bounds check only blocked values that were too large, so a negative index bypassed it entirely. No entitlements were required to trigger it.
Fuzzing the DCP Display Co-Processor Firmware
To reach the DCP display co-processor firmware, the team reverse-engineered the DCP architecture and its RTBuddy channel to the application processor, then built a custom fuzzer. It triggered a large number of crashes, with bug reports relayed from DCP to AP through RTBuddy, giving direct crash log visibility. Fuzzing also surfaced an unnoticed video interface reachable from user mode without any entitlements. One vulnerability found through that interface, shown in the DCP firmware fuzzing crash log (19:52), was confirmed by Apple to affect current iOS and macOS. Registers R2, R8, and the link register are directly user-controlled.
What Apple’s Graphics Stack Teaches About Defense
Apple moved IOMobileFramebuffer’s core functions into DCP firmware to reduce direct attack surface. That bought roughly six months before researchers caught up, the same lag seen after the 2020 refactoring. The code is still there; just harder to reach. Three gaps stand out: static analyzers flag signed-versus-unsigned comparisons, yet one slipped into production. A bug submitted in October 2024 will not be fixed until fall 2025, suggesting full refactoring rather than point patches. Across AMD, Intel, AGX, and DCP, every layer showed the same pattern: unsanitized user input reaching a kernel memory write.
“new feature always means new attack” Wayon Chen
Notable Quotes
subsystem is too complex to be perfect. Wayon Chen · ▶ 1:58
local deny of service shouldn’t qualify Wayon Chen · ▶ 9:09
new feature always means new attack Wayon Chen · ▶ 24:12
Key Takeaways
- Apple’s graphics kernel extensions for AMD, Intel, and AGX all contained user-controlled OOB write primitives.
- IOMobileFramebuffer is reachable from browser content and has had 16 CVEs, four exploited by APT groups.
- Moving vulnerable code to DCP firmware raises the bar slightly but leaves root causes unpatched and reachable.