Memory corruption in Apple IOHIDFamily

Repository contains two standalone Xcode iOS proof-of-concept apps targeting Apple IOHIDFamily race conditions associated with CVE-2026-28992. The structure is split into `AOPPanicPoc/` and `UAFPoc/`, each with standard iOS app scaffolding (AppDelegate, SceneDelegate, storyboard, plist, main.m). The substantive exploit logic is concentrated in `AOPPanicPoc/AOPPanicPoc/ViewController.m`, a large Objective-C file that dynamically resolves IOKit routines and drives repeated `IOServiceOpen`, `IOConnectCallMethod`, and Mach port teardown operations against `IOHIDEventService` / `IOHIDEventServiceFastPathUserClient`. The README and report describe the second PoC (`UAFPoc/`) even though its main exploit source is not present in the provided listing, indicating the repo is primarily a research/PoC package rather than a polished exploit kit. Main capability: from a normal sandboxed iOS app with no special entitlements, the code abuses selector 0/open authorization by supplying XML keys `FastPathHasEntitlement` and `FastPathMotionEventEntitlement`. After bypassing the gate, it performs high-frequency close/reopen and teardown races across multiple connections. One vector aims to trigger a kernel use-after-free in provider client collection handling (`openForClient` vs `closeForClient`/`didTerminate`), producing MTE tag faults or kernel data aborts. The other vector rapidly creates and destroys gated connections to saturate SPU/AOP mailbox handling, causing an AOP firmware assertion and device reboot. No network communication, C2, or remote endpoints are present. This is a local mobile kernel DoS/reliability PoC, not a privilege-escalation framework or payload delivery tool. The expected result is kernel panic / coprocessor panic and reboot of affected iPhones/iPads.

Repository contains three standalone Xcode iOS PoC apps plus CI packaging workflow and documentation. The primary purpose is security research and reproduction of Apple kernel/driver vulnerabilities reachable from a normal app context. Structure: UAFPoc/, AOPPanicPoc/, and M2ScalerPoC/ each contain a minimal Xcode project, Info.plist, and a single Objective-C main.m implementing the PoC logic. .github/workflows/build.yml builds unsigned IPAs for all three apps on macOS runners. README.md documents CVE-2026-28992 in detail and also references the AppleM2ScalerCSCDriver issues. Main exploit capabilities: 1) UAFPoc targets CVE-2026-28992 in IOHIDFamily FastPathUserClient. It crafts an XML property list containing FastPathHasEntitlement and FastPathMotionEventEntitlement to satisfy gate/open checks, opens 15 connections to IOHIDEventService, then races one thread repeatedly calling selector 1 (close) and selector 0 (reopen/gate) against eight threads repeatedly calling selector 2 (copyEvent) on other connections. The intended result is a provider-side use-after-free leading to kernel panic/reboot. 2) AOPPanicPoc also targets CVE-2026-28992 but exercises a different race: multiple persistent connections are gated, opener threads continuously close/reopen them, and the main thread repeatedly opens batches of probe connections and destroys their Mach ports with mach_port_destroy to trigger asynchronous didTerminate/teardown while other threads are reopening. The comments state this can free provider-facing state concurrently and saturate SPU/AOP mailbox handling, causing an AOP watchdog timeout and device reboot. 3) M2ScalerPoC targets AppleM2ScalerCSCDriver and appears to combine vulnerability research for CVE-2025-43510 and CVE-2026-43655. It opens the AppleM2ScalerCSCDriver service (trying userType 0 and 1), probes selectors 0-15 with zeroed input to map the attack surface, performs a boundary sweep for an alleged OOB read using crafted MultiPlaneDescriptor structures on methods 5-7, and then launches a COW race phase that may reboot the device. Unlike the IOHID PoCs, this one logs detailed output to Documents/poc_log.txt. No network C2, remote delivery, or exfiltration behavior is present. The attack vector is local-only: the code must run as an app on a vulnerable iOS device. The repository is a real exploit/PoC set rather than a detector; however, it is destructive in the sense that successful exploitation causes kernel panic and reboot rather than privilege escalation or shell access.

Repository contains two standalone Xcode iOS application PoCs targeting CVE-2026-28992 in Apple IOHIDFamily, specifically IOHIDEventServiceFastPathUserClient. It is not part of an exploit framework. The repo structure is split into two app projects: UAFPoc/ for a kernel use-after-free/copyEvent race and AOPPanicPoc/ for an AOP/SPU panic via termination race and mailbox saturation. Most files are standard Xcode scaffolding (AppDelegate, SceneDelegate, storyboards, plist, assets); the substantive exploit logic is concentrated in AOPPanicPoc/AOPPanicPoc/ViewController.m, while README.md and report.txt document both bugs in detail. Core capability: from a normal sandboxed iOS app with no special entitlements, the code dynamically uses IOKit APIs to locate/open IOHIDEventService with IOServiceOpen(..., type=2), creating IOHIDEventServiceFastPathUserClient connections. The exploit abuses an authorization bypass by supplying XML properties FastPathHasEntitlement and FastPathMotionEventEntitlement to selector 0 (open), which the vulnerable gate incorrectly trusts. After bypassing the gate, the PoCs create high-frequency connection lifecycle races using IOConnectCallMethod selector 0/1 and mach_port_destroy or mach_port_destruct to trigger asynchronous teardown paths. The documented UAF vector uses multiple connections to the same provider so that close/terminate frees provider-side objects while concurrent open/copyEvent activity iterates shared collections under inconsistent locking, producing a kernel UAF and panic/reboot. The AOP panic vector repeatedly opens and destroys gated connections to SPU-backed providers, saturating the outbox and causing an AOP firmware assertion and device reboot. No remote C2, network scanning, or external callback infrastructure is present; this is a local denial-of-service/kernel crash PoC rather than a code-execution implant. The exploit appears to be proof-of-concept quality: reliable enough to reproduce crashes on listed test devices, but focused on panic/reboot rather than privilege escalation or a post-exploitation payload.