The vulnerability is in the process, and this was the test.
> You really think the Linux kernel guys would change their process if you did this? They'd still do the same things they do.
If they're vulnerable to accepting patches with exploits because the review process fails, then the process is broken. Linux isn't some toy, it's critical infrastructure.
> You can test the process without pushing exploits to the real kernel.
No, you can't, because that is the test! If you manage to push exploits to the real kernel, the test failed. If you get caught, the test passes. They did get caught.
You totally can... contact the kernel maintainers, tell them you want them to review a merge for security and they can give you a go/no go. If they approve your merge, then it's the same effect as purposely compromising millions without compromising millions.
Again, that's not the same, because then they will look for problems. What you want to test is that they're looking for problems all the time, on every patch, without you telling them to do so.
If they don't, then that's the vulnerability in the process.
> because then they will look for problems. What you want to test is that they're looking for problems all the time, on every patch, without you telling them to do so.
Telling them in advance will potentially make them more alert for problem coming from specific source. It will introduce bias.
The best they can do is notify the maintainers after they got the result for their research and give the maintainers an easy way to recover from vulnerability they intentionally create.
Do you understand how dumb that sounds?