First public macOS kernel memory corruption exploit on Apple M5

Original Article ↗ Hacker News Discussion ↗

A newly published kernel memory corruption exploit against Apple’s M5-based macOS raises questions about how it bypassed advanced defenses like ARM’s Memory Tagging Extension and Apple’s own bounds-checking efforts. Commenters debate the effectiveness and deployment of hardware-assisted protections, the slow migration to memory-safe languages such as Swift and Rust, and how powerful LLM-assisted tools like Mythos are accelerating both vulnerability discovery and the broader offensive–defensive security arms race. Many also warn that organizations without strong security teams or update practices may be increasingly exposed as AI lowers the cost and complexity of sophisticated attacks.

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.