[BugsBunnySan]

It might have something to do with what the article's author writes as the moral 'lying is bad'... And understanding why it is bad if code lies about stuff.

I can imagine someone looking at that code and the part where the kernel says one thing (I don't need write permissions) when that is not actually true and thinking that's a bad situation, that smells bad.

And the fact that the kernel does this is bad enough, but it's really just a symptom of an underlying problem. And that problem is the fact that the kernel code has to do this lying to prevent a loop, Which seems like bad code design (or the result of a hundred other factors that make it look, at first glance, like bad design). And the solution was done in a sloppy manner (dropping that write flag, instead of being honest and doing the little bit of extra work, which they did in the fix for the exploit with that extra flag).

And then maybe if you have experience with this stuff you might recognize that within this code there's that race condition.

And from those two things you might go see if other things nearby in the code can help you exploit it and it probably evolves from there into this very complex exploit.

The thing is, I think, one person looks at that code and is like, yeah the kernel lies a bit here, but whatever, sure it's grand. And in 99.999% percent of the time it is and you're fine with that and walk on.

And another person, who has Hacker Nature, might think like, a) this is bad as the tip of an iceberg is bad for a ship and more importantly b) I wonder what happens in the 0.001% of the time where this isn't fine...

Or, of course, maybe someone was standing on the edge of their toilet hanging a clock, the porcelain was wet, they slipped, hit their head on the sink, and when they came to they had a vision of this exploit. ;)

[mannykannot]

Perhaps the talk[1] given by Bryan Cantrill in 2015, and mentioned in footnote 1 of the article, may have alerted someone to the possibility that there might be something exploitable here? In addition, any of the other online discussions of madvise(,,MADV_DONTNEED), mentioned in that talk, may have attracted someone's interest.

This exploit seems to lie at the intersection of several things that I guess might indicate a higher-than-average risk of exploitability: shared memory, special provisions for debugging access to running processes, complicated and unintuitive (if not broken) semantics, and concurrency.

[1] https://www.youtube.com/watch?v=bg6-LVCHmGM&feature=youtu.be...

[taneq]

> This exploit seems to lie at the intersection of several things that I guess might indicate a higher-than-average risk of exploitability: shared memory, special provisions for debugging access to running processes, complicated and unintuitive (if not broken) semantics, and concurrency.

I think this is a great general rule. Any one of these things is a reason to tread lightly. All of them at once? Here be dragons.