It would be spotted right away by anyone
    remotely competent who glanced over it.

I'm not so sure. I'm a professional programmer mostly working in C++, and I didn't see the problem on first read-through. It took looking carefully before I saw it, and if I hadn't already known that these two lines contained a vulnerability I might not have noticed. I could see this being missed in a code review.

Going back to my earlier point, its success relies on people not seeing it. So I would think its ability to pass a code review would ultimately depend on how many other lines of code it has to hide amongst. If you are reviewing a huge diff and this is hiding somewhere, then OK, maybe I buy it, but it's pretty transparently wrong.

Another test it fails: even if it were == as they are trying to make people think, why would this return EINVAL only if the user is root? There aren't a lot of real world examples where you would want that. It pops out right away as a bogus check that makes no sense, and surprise surprise, it also sets the uid to 0, my guess is in a place where it makes no sense to even look at uid, and very superficially hiding as a "rookie mistake"...

Any professional programmer should be hesitant making claims like this: it's easy to see if you have an isolated fragment and are primed to be thinking about security. It's a much different story if you received something like this as part of a big patch and making an effort to be particularly vigilant. We have a such a long history of finding bugs like this which made it into production because this is an easier mistake to make than you claim.

It's easy to thump your chest and assume that you're smarter than those developers (which is almost certainly wrong) but that misses the underlying lesson that humans will make mistakes and the likelihood goes up with the complexity of the task. That can be switching to a language which bans problematic behaviour, automatic use of linters and other tools, rigorous code reviews, etc. but in each case you're making environment safer rather than trying to find perfect developers.

I suspect you are taking my comment as a personal insult rather than reading it for the meaning I intended. The point I was trying to make is that the skill involved here was hiding the lines in a large source tree and hiding the history. The actual lines of code are unremarkable, absurdly incorrect when taken in isolation, and not where the clever part of this attack lies. The author of the article is stating it as something else.

See also my reply to cbr where I make essentially your same point: the way to get this past a code review is make it part of a large diff.

It's not so much a personal insult as the common tendency most people have to base decisions on best rather than average performance. This essentially devolves to the Deming/TQM/Toyota/etc. school of management where you focus on making the system tolerate human error rather than hoping your humans consistently perform well.

That said, I do disagree that this is easily detected – I would bet that a significant percentage of C developers would not notice this if it wasn't mentioned in the context of a security problem. Linux kernel developers are [hopefully] well above average but … there's a reason why so many style guidelines feature this one prominently and it's not because few people have made this mistake.

Surprised at downvotes. Putting foo = 0 in a test for an if statement is something that even I can spot, and I am not a professional programmer and have had no formal training in programming other than an Algo 60 course at University way back in the last century.

The author of the code if malicious must have realised that it would not pass any kind of code review.

PS: I tend to discount 'tone' when reading blog pages as getting the 'tone' right is the kind of thing professional authors do.

As a professional programmer, I spotted the error on my first read through, but it wasn't a fair test because the code wouldn't have been there if there wasn't a problem. Had I just been scanning the code quickly without being in a state where I was alerted to look for an issue I have no idea if I would have seen it.

In any case, this is something a competent lint tool or static code analyzer would warn about, which makes a good case for people using such tools as part of their normal process.