An answer to this question would provide insight and references about how the linux kernel source code is reviewed prior to be released?
Particular interesting aspect of this question to me are:
- Who and how many persons review the code that is provided, i.e. via a pull request?
- Is there a change that a backdoor could go undedected, in particular considering firmware blobs?
- Are static/dynamic code analysis tools used, and if so to guard against accidental bugs only, or also against deliberate backdoors implants?
Info: I have looked at the LKML FAQ which provides the following statement related
How do I get my patch into the kernel?
(RRR) Depending on your patch there are several ways to get it into the kernel. The first thing is to determine under which maintainer does your code fall into (look in the MAINTAINERS file). If your patch is only a small bugfix and you're sure that it is 'obviously correct', [...]
[...] here's another important bit: one purpose of the list is to get patches peer-reviewed and well-tested.[...]
The core of the question is some insight, what this 'obviously correct' and peer-reviewed (e.g. who, how many?).
For sake of a concrete example, I looked at the example of the commit log for the staged
rtl8188eu wifi chip device driver, found in
- number of commits modifying file of
git log --format="%x00%h%n%an%n%cn%n%s" --name-status | tr '\0\n' '\n\0' | grep -a '8188eu' | tee commits | wc -l
- number of authors 190 persons
sed 's/^[^\x00]*\x00//g;s/\x00.*$//g' <commits | sort | uniq | wc -l
- number of commiters 12 (Al Viro, David S. Miller, Greg Kroah-Hartman, Ingo Molnar, Jeff Kirsher, Jiri Kosina, Johannes Berg, John W. Linville, Kees Cook, Linus Torvalds, Michael S. Tsirkin, Peter P Waskiewicz Jr)
sed 's/^[^\x00]*\x00//g;s/^[^\x00]*\x00//g;s/\x00.*$//g' <commits | sort | uniq