If you can come up with a backdoor that requires the non-obvious interaction of multiple parts of the kernel (or parts of the kernel and certain user-space acti

If you can come up with a backdoor that requires the non-obvious interaction of multiple parts of the kernel (or parts of the kernel and certain user-space actions) then it would be reasonable to break up the necessary changes and slip each one in as a part of a larger demonstrable improvement to each specific subsystem. For example (completely hypothetical), you could create a race condition in the kernel's page allocator that can be reliably be triggered by filling up physical ram and then forcing the kernel to allocate more memory for itself by filling up the proc table past a certain size. So in one patch you include an improvement to the allocator that has this obscure race condition but otherwise makes the allocator work much faster. Then in another patch you increase the maximum size of the proc table (under the pretense of supporting some big-iron system that practically no one outside of some HPC centers own) so that filling it up will force a kernel page allocation. So then you can force the exploit to occur on any system with both patches installed simply by allocating all the physical ram and then creating a ton of do-nothing processes that max out the proc table. If you are an organization like the NSA you could even have the submissions come from what appear to be completely independent developers. It is kind of the exploit version of "parallel construction." You know the exploit you want to put into the kernel, you just need to come up with reasonable sounding explanations for every little patch that ultimately gets you to the end goal.