Keep in mind that this is a dangling pointer problem that is a stupid design mistake and Apple's own kexts used the same vulnerable pattern for years before Project Zero had to disclose it to Apple after which there were two failed mitigations and a fix that changes core OS code!

That's not very justifiable no matter how many storms and twisters you throw in the mix ;) I am not going to argue but for OS development this looks bad that it wasn't even looked at much rather fixed for so long given many of Apple's kexts had the same issue.

[Also this isn't an isolated problem by the way - look up the thread and you'll find two other egregious errors including one involving execve that was pointed to Apple in vain. Not long ago I could just remove and insert a kmod and that would lock up the system - go ahead and argue that's not a hot path or nobody does that but it does speak to general lack of code and testing quality. To their credit Apple fixed that particular one though when I reported them.]

The dangling pointer isn't the interesting part of the bug --- dangling pointers are, to a first approximation, the key component of all UAFs, which are a 15 year old bug class. The interesting bit about this bug is how they arrived at the dangling pointer: they had to manipulate at least three different object lifecycles in the kernel, one of of which involved a credential passing trick that is not super common in normal code.

I disagree that this is a simple bug that anyone should have been able to find. If you'd like to put money on whether or not this is going to win a 2017 Pwnie Award, I would be happy to take your money.

When you take money for writing and maintaining an OS you have to be competent to avoid fundamental design issues like this when you're going to have a bunch of downstream users of the code!

Read the TLDR - exploitation of dangling pointers aside you can't write code and/or design APIs that does or makes it easy to do what the TLDR says - hold or use a task struct pointer and expect the euid of that task to stay the same. Many many places in the kernel do this and there are a great many very exploitable bugs as a result.

Ian Beer certainly is talented but that doesn't excuse Apple being so sloppy!

Aha! I think I understand what has you confused. You seem to think that the TLDR describes some basic rule of XNU programming that people were already aware of and expected to follow. No. Ian Beer invented that rule. In this post. That's why the bug is such a big deal; it's why we call it a "new bug class". It's also why it's the TLDR of the post.

Wow straight up conclusion - I had it confused, right!

It's not a, pardon me for the expression, fucking XNU specific programming rule - it is a general rule that was invented long before Ian got to it! You don't hold a reference counted pointer and operate on it without taking a :gasp: reference first - having that shit in your sample code is just, well extra shitty!

Also, separately from the dangling pointer issue, the first sentence of the post is literally - This post discusses a design issue at the core of the XNU kernel!

You are describing only the first big in this document. There are four. The timeline we're commenting on is for the last 3, which are not UAFs.

AFAIU, the dangling pointer problem wasn't a defect in the kernel; it was a problem introduced by some module authors who misunderstood the ownership semantics of the API. It might not even have been a pointer, per se, but I guess that's beside the point.

The larger problem was an inherent TOCTTOU bug in the interface semantics between the BSD subsystem and Mach. AFAIU that wasn't a dangling-anything problem; the reference was still valid. It was a logic and design problem that could happen in any language, even in Rust, and even without resorting to unsafe code.