But what value does adding an arbitrary unconnected commit have to an attacker? The only sane goal would be sneaking exploit code into a "released" version that will be shipped.
In order to do that, you need to somehow get Linus to merge it successfully. And that doesn't work per git's design.
If all you want is to have "exploitable" commit IDs in the kernel git, you don't need to do anything sneaky at all! They're already there, being historical bugs that have since been fixed.
But that's just HEAD. No offense, but so what? Clearly anyone (sane) running off of a development branch isn't doing so on a security sensitive system. It's an exploit, but only of development systems and a tiny handful of hacker's personal boxes. The value there to an attacker is very low.
What you can't do is inject code that ends up in 3.1-rc5, because before that gets tagged Linus (and a lot of other people) would have to do a merge that would fail inexplicably.
But to be clear: yes, with access to the repository you can (for a brief moment until it's noticed) inject exploit code that will be picked up by anyone building and running an untagged branch HEAD.
Ubuntu does daily kernel builds and many people run that kernel - to see if some bug has been fixed, to get support for their newer hardware etc. Lots of reasons perfectly sane people can end up testing a daily build.
In order to do that, you need to somehow get Linus to merge it successfully. And that doesn't work per git's design.
If all you want is to have "exploitable" commit IDs in the kernel git, you don't need to do anything sneaky at all! They're already there, being historical bugs that have since been fixed.