Pardon MIE? - ironPeak Blog
Pardon MIE?<br>Sat May 23, 2026
Pardon MIE?<br>Sat May 23, 2026
Apple’s Memory Integrity Enforcement is no joke. Five years of design, brand-new M5 silicon, hardware memory tagging on the kernel heap, hardware-locked read-only zones for the kernel’s crown jewels, and a privileged monitor sitting above the kernel that refuses every unauthorised page-table change. It’s the most serious kernel memory-safety stack any consumer OS has shipped. And it still got bypassed. A three-person shop with an AI sidekick walked through it in five days, with two bugs and a clever idea. Here’s my rundown of how they achieved it, no PhD required.<br>Skip ahead if you want:<br>The bug, in 60 seconds<br>The fix, in two instructions<br>For defenders<br>For exploit writers<br>Why memory safety matters<br>Almost every “your iPhone got hacked” story you’ve ever read comes back to the same root cause: a memory bug. A pointer that pointed at the wrong thing. A buffer that wrote one byte too many. A struct that got reused after it was supposed to be freed.<br>It’s not the user clicking a sketchy link. It’s not a stolen password. It’s the kernel reading from a piece of memory and trusting it just a little too much.<br>Pegasus, the NSO Group spyware that ended up on journalists and activists worldwide? Memory bug. The WebKit zero-clicks used in targeted operations all through the 2020s? Memory bugs. The checkm8 jailbreak that owned every iPhone from the 5s through the X? Memory bug. The T2 vulnerability I wrote about a few years ago? Same family.<br>Google’s Project Zero has been counting these for years. Roughly 70% of high-severity vulnerabilities across all major software products are memory-safety bugs. Microsoft counted theirs and got the same number. Chrome did, Firefox did, Apple did. The whole industry agrees: this is the problem.<br>So what does an attacker actually do with a memory bug?<br>In the worst case, anything they want. The kernel is the program that runs every other program. If you can corrupt the kernel’s memory, you can rewrite the table that says “this process is allowed to read your photos”, or “this user is uid=501”. You can install something that survives a reboot. You can read every message the device has ever sent. You can flip the camera on without the LED. The phone you bought to keep your life private is now someone else’s diary of your life.<br>This is why Apple, Microsoft, Google and the chip vendors have been pouring engineering at hardware-level memory safety for a decade. Compiler hardening, safer allocators, sandboxing: they all help, but they’re a leaky bucket. The bugs keep coming. The thing that actually works is making the bugs unexploitable even when they exist. Stop trusting the software to be correct; build the hardware to refuse incorrect operations.<br>That’s the bet MIE is making.<br>Recap: what is MIE supposed to do?<br>If you’ve followed Apple’s security marketing in the last year, you’ve heard MIE described as a “generational leap”. It’s three pieces, stacked.<br>Memory tagging (EMTE). Every chunk of memory the kernel hands out gets a hidden label, a tag. The pointer you use to reach that chunk has the same tag baked into its upper bits, where it doesn’t change the address. On every access, the CPU checks: does the pointer’s tag match the memory’s tag? If not, your process dies on the spot. Apple’s version is synchronous, which means the check fires on the access itself, not later. You can’t guess tags by probing because the first wrong guess kills you.<br>Read-only zones. Some kernel structures are so juicy they get extra protection. Things like ucred (your process’s user ID), the Mach task control block, the sandbox table, the codesigning state. They live in a special region where the page tables themselves mark the pages as unwritable. Even ring-0 kernel code can’t touch them. The hardware MMU refuses.<br>One door in. Exactly one kernel function is allowed to mutate read-only-zone pages: _zalloc_ro_mut. It briefly marks a page writable, does its write, marks it unwritable again. A higher-privileged thing called the Secure Page Table Monitor watches every page-table change and refuses if anyone else tries. From the kernel’s own perspective, “only _zalloc_ro_mut writes here” is unbreakable.<br>Stack those three together and you get MIE. Most kernel memory is tag-protected. The crown jewels are page-table-protected behind one audited writer. Pretty good design, honestly.<br>What just happened?<br>On 11 May 2026 Apple shipped macOS Tahoe 26.5. Buried in the security notes was a one-liner:<br>Kernel. Available for Mac computers with Apple Silicon. An app may be able to cause unexpected system termination. Credit: Calif.io in collaboration with Claude and Anthropic Research. CVE-2026-28952.
“Unexpected system...