Guise? They distributed source and the patch is not at all obfuscated. Eight consecutive lines like "cred->uid = 0;" and then printk("now you are root\n"), so it's really easy to spot in a diff.
Don't see why they did it, but they did in in the plainest and most visible way I can imagine.
They distributed source and the patch is not at all obfuscated.
Which is exactly my point.
Say you are a government organization that requires a backdoor. You can make a very sophisticated backdoor. When it's found it is clear that it is probably an intentional backdoor (e.g. Dual_EC_DRBG). Or you can make a very obvious backdoor that is disguised as a debugging option that you forgot to disable, an obvious logic error, etc. For such backdoors, it's easy to argue that it was just sloppy programming (in contrast to an intentional government-requested backdoor), so people will assume the simpler explanation (as in Hanlan's razor).
We have learned from the Debian OpenSSL saga [1] that trivial programming errors in critical software can go unnoticed for years. I don't think the Debian OpenSSL bug was government-mandated, but it's easy to see that this is a very attractive route: the bug caused only 32,768 unique private keys to be generated (great for spying), most people will believe it's a true programming error, you pay the person/company that introduces the bug royally for taking the blame.
Assume the printk("You're root now") had not been there. Would that increase your estimate for the probability of an intentional backdoor, or reduce it?
Two rival businessmen meet in the Warsaw railway station. "Where are you going?" says the first man.
"To Minsk," says the second.
"To Minsk, eh? What a nerve you have! I know you're telling me you're going to Minsk because you want me to think that you're really going to Pinsk. But it so happens that I know you really are going to Minsk. So why are you lying to me?"
It's not THAT easy to spot in a diff because a lot of these kernel source code repository dumps are basically 1 single commit with the entire source code; any existing kernel.org git history is lost. So you'll have to figure out which mainline revision they started working from, and manually diff with that (which will probably turn into a huge mega-patch).
What you're saying is that the diffs are hard to work with in general. What I'm saying is that in a diff (be it large or small, a single commit or many), the code they wrote is the most visible and understandable way to do what they did.
What better way to disguise a backdoor than an apparently deliberate "debug" utility? I mean, if they have to distribute source code sooner or later (which they do since Linux is GPL), this looks much more innocent than any super obfuscated "hidden" source code that would be discovered eventually anyway.
Not saying this was the actual intention here, but it'd be a plausible way to go about it. It certainly appears the backdoor is running on lots of devices in the wild before it got noticed (even when it's this obvious in the diff(!)), so "mission accomplished"? :)
Don't see why they did it, but they did in in the plainest and most visible way I can imagine.