First public macOS kernel memory corruption exploit on Apple M5

Original Article ↗ Hacker News Discussion ↗

Exploit & MTE / MIE

  • Many commenters note the writeup is light on technical detail; several want more info on how the exploit bypassed Apple’s Memory Integrity Enforcement / Arm MTE.
  • Explanation offered: this appears to be a “data-only” attack, which may not trigger MTE because it doesn’t violate tagged bounds in a way the hardware detects.
  • Some speculate GPU memory/shader paths might not be covered by MTE/PAC, possibly providing a data-only primitive, though how this yields LPE is debated.
  • There is surprise that Apple’s aggressive use of compiler-based bounds checking (“fbounds”) did not cover this code path; unclear whether due to performance, tooling limits, or simple omission.

Bug Bounty Value & Severity

  • Commenters classify this as a local privilege escalation (LPE), not a zero‑click RCE.
  • Estimates for Apple’s bounty range around ~$100K for LPE, with speculation that a more weaponized chain (e.g., from a beta, “locked mode”, unauthorized access framing) could be worth much more, but details are uncertain.

MTE, Memory Safety, and Swift

  • Some express disappointment that MTE didn’t prevent the bug; others stress MTE still blocks many classes of vulnerabilities and makes ROP/JOP harder.
  • Discussion on why Apple hasn’t fully moved to Swift in the kernel: Swift is being used more (e.g., Safari parser, secure enclave, embedded/firmware), but wholesale rewrites of large kernels in safe languages are seen as unrealistic.
  • Compiler-based protections (bounds checking, strict memory safety in Swift) are seen as partial but important defenses.

LLMs, Mythos, and the Security Arms Race

  • Strong focus on how LLM-based systems (like Mythos) accelerate finding complex exploit chains; this macOS exploit reportedly went from bug to working exploit in about a week.
  • Some see this as the start of an era where both attackers and defenders can rapidly generate and refine exploits and defenses.
  • Skepticism that LLMs alone replace expert security researchers; instead they amplify skilled practitioners while still requiring human filtering of false positives.
  • Concerns that many organizations lack proper security teams; LLMs could enable broad, automated probing of “low-hanging fruit” in legacy, unpatched software.

Broader Security Reflections

  • Debate over whether “perfect security” is theoretically attainable versus practically too expensive, and whether security should focus on correctness or compartmentalization.
  • Worries about AI-generated code increasing technical debt and eroding human understanding of systems, balanced by optimism that LLMs could also generate better documentation and analysis tools.