Actually, you missed the point of everything. > I was not talking about the article's author First. I said "the author's intention is criticizing the ad-hoc,

Actually, you missed the point of everything. > I was not talking about the article's author First. I said "the author's intention is criticizing the ad-hoc, error-prone approach" on fixing Spectre vulnerabilities. Please consider what did I really mean. I meant: It is believed that this type of mistake is inevitable, regardless of who writes the code, in the end, a mistake like this one will be made, and probably have already been made, much earlier than the reported one, and still undetected. If you get this message, "who did it" becomes a unimportant question. Second, it's not some 0day fixes, but a Spectre fix, precisely, a Spectre variant 1 fix. This distinction is important - everything today is still largely vulnerable to Spectre to an extent, and this situation is unlikely to change. For Spectre v1, the outcome is a simple infoleak, among all Spectre vulnerabilities, its risk considered relatively low. The current Linux kernel's approach to Spectre v1 is plugging them one by one. As the Linux kernel documentation explains, > Vulnerable code uses nospec accessor macros for "bounds clipping", to avoid any usable disclosure gadgets. However, this may not cover all variant 1 attack vectors. It means a lot of potential Spectre v1 vulnerability already exist in the kernel (and elsewhere), but they're probably not too useful for the attack without another exploit. Third, the defective patch does not introduce any vulnerability. The original code was a potential Spectre v1 exploit gadget, and a Chinese developer noticed that in a code review, and submitted a patch to fix it. However, the patch generated a compiler-warning. Linus Torvalds fixed it, but it evaded the detection from maintainers, and finally a broken version created by the stable kernel maintainers got merged into all stable trees. And let's assess the situation. 1. More than one potential Spectre v1 vulnerability gadgets already exist in the kernel, regardless of anyone's actions. It means all the deployed production systems all across the Internet are already somewhat vulnerable. 2. In the kernel ptrace code, there was a Spectre gadget. Again, it means all the deployed production systems all across the Internet are already vulnerable to it. 3. A Chinese developer submitted a "fix". Linus noticed the fix was broken, but the kernel maintainers picked up the old patch. 4. As a result, (1) no new fix is introduced, no new bug is introduced, (2) all the deployed production systems all across the Internet are still vulnerable to the same Spectre gadget, just like before. And (3) the head of a infosec company noticed it and published an article to criticize the mainline kernel. (4) It created a lot of buzz and the problem is fixed. There is nothing even remotely close to "the entire avalanche in the code repository", the code repository worked exactly like before. In conclusion, we ask, cui bono - "to whom is it a benefit?". If I was the security service of the Chinese government, my intention could never be inserting a malicious vulnerability, because the same type of vulnerability already existed, I probably know a lot of different ones as well. Further, even if the gadget in ptrace is the only vulnerability I know, by submitting a false fix, it did not introduce any additional vulnerability, but in fact greatly increased the chance of the fix being noticed and fixed. I gained nothing by going through all of these troubles by first creating a good patch which generates a compiler warning to trick maintainers to ruin the patch while attempting to fix it. So we can rule out the "Chinese hacker" meme, it doesn't make sense at all. If you still insist, the only possibilities remained are, 1. The intention of the attacker by submitting a false fix is to mislead the kernel developers to believe the fix is good. So that nobody would notice the same problem in the future, so that I can use it as a long-term backdoor, not only a short-term one. Certainly possible, but unlikely. By submitting the code, the risk of being discovered is much higher than the benefit of keeping the original vulnerability undetected, because it generates a compiler warning. Even worse, regardless of the compiler warning is being noticed or not, in either way, I ended up risking to patch my own backdoor. Not to say the original vulnerability is something of little value. 2. The intention of the attacker by submitting a false fix is to start a propaganda campaign and discredit the competence of kernel developers. Or to examine the abilities of kernel maintainers to avoid making mistake, or some other grand scheme of chess. If I am the project leader of a Chinese operating system, perhaps I'd like to do this, as it would be beneficial to me for citing it as my evidence later to push my project's agenda. Another scenario would be that the author of the article and his infosec company has connection to the Chinese government, so he asked the Chinese security service to do an inside job, and he would expose it later to increase the sales of grsecurity. Again, certainly possible, but unlikely, and very stupid. In conclusion, if you cannot understand even the basic facts (such as the nature of Spectre vulnerability), fail to comprehend the basic idea of an simple article like this one, and fail to understand the comments, I suggest you to stop posting uninformed comments.