Re:First public macOS kernel memory corruption exploit on Ap...
by pjmlp on Thursday May 14, 2026 @03:56PM
(#48140376)
Quite strange indeed, given that was one of the main points on their security conference a few months ago.
Re:First public macOS kernel memory corruption exploit on Ap...
by vsgherzi on Thursday May 14, 2026 @04:27PM
(#48140790)
I can only imagine that
1. it’s to performance sensitive
Or
2. The os is so darn large it’s hard to recompile everything
Re:First public macOS kernel memory corruption exploit on Ap...
by kenferry on Thursday May 14, 2026 @10:57PM
(#48144039)
I worked at Apple for a long time. The OS gets fully recompiled regularly.
A simultaneous total world build is relatively rare (is that needed here?), but it does happen. Sometimes new compiler versions or features need this.
Re:First public macOS kernel memory corruption exploit on Ap...
by vsgherzi on Friday May 15, 2026 @12:38AM
(#48144620)
Hm that leaves more questions for me. Why does this path not have bounds checking, is think perhaps a limit of the clang flag or is it more simply a mistake of omission on apples part. Either way it seems like a bad look. I wish we’d get a post mortem
Re:First public macOS kernel memory corruption exploit on Ap...
by asimovDev on Friday May 15, 2026 @01:50AM
(#48145007)
I dunno if that's sensitive information, but how long did a build usually take?
Re:First public macOS kernel memory corruption exploit on Ap...
by kenferry on Wednesday May 20, 2026 @01:48AM
(#48203564)
I wasn't close enough to that to know how long a world build took. Didn't seem like it was too crazy though. Incremental (non-world) builds of the OS come out every day.
Re:First public macOS kernel memory corruption exploit on Ap...
by aiscoming on Thursday May 14, 2026 @07:04PM
(#48142409)
could be a different type of data only attack, which doesnt override the boundaries
Re:First public macOS kernel memory corruption exploit on Ap...
by vsgherzi on Thursday May 14, 2026 @07:25PM
(#48142558)
Well it’s memory corruption so I think it’s pretty safe to assume it’s a bounds issue. I’m not sure if it’s possible to get this with something like type confusion tho I could be wrong here.
(https://www.usenix.org/publications/loginonline/data-only-at...)
This makes more sense. You don't trigger MTE since you're not doing anything for force MTE to take action the program isn't actually changing.
My other question would be, why didn't apple use fbounds checking here? They've been doing it aggressively everywhere else.
MTE plus fbounds checking everywhere should lead to an extremly hardened OS