Few days ago an unusual incident occurred, which shook the Linux kernel community, and that is Linus Torvalds ordered the immediate suspension of Kees Cook's account on kernel.org., after detecting the existence of manipulated commits in this developer's Git repository.
Kees Cook, recognized for his leadership on the Ubuntu security team and for maintaining more than a dozen security-related subsystems of the kernel, was temporarily banned from submitting changes while the facts were clarified.
Alteration of authorship and signatures in the Kees Cook repository
The problem arose from a change incorporation request.s to the 6.16 kernel branch, in which Linus identified references to a repository that contained commits manipulated with his name as author and confirmer, despite not having done them himself. One of the most serious examples was the existence of a duplicate commit, identical in content to the original but with a different SHA1 hash, which falsely included Linus Torvalds' signature.
These changes could not be attributed simply to an accidental errorl during a git rebase operation, since they involved massive modification of sensitive information, including over 6.000 rewritten commits, 330 of which had Linus's name as the author.
Torvalds' reaction: suspicions of deliberate manipulation
Linus Torvalds did not hide his concern and described the events as potentially malicious:
"One or two rewrites could be a mistake. But thousands of them, many with my forged signature, are not," he declared.
Given the magnitude of the changes and the risk to the integrity of the official kernel tree, Torvalds asked Konstantin Ryabitsev, kernel.org infrastructure administrator, qto block Kees Cook's access until the situation is clarified.
In response, Kees Cook explained that he had had recent technical problems that could have triggered the incident. He said, Your SSD drive was experiencing errors during copy operations, which had caused corruption in several repositories. After these errors, he attempted to recover the state of his repository using git rebase and various automation tools.
However, these operations were performed on critical branches, such as for-next/hardening and for-linus/hardening, which led to an accidental modification of the repository history, including the change in the authorship of commits. Despite his explanation, Linus was skeptical.:
"I don't understand how an accidental overtaking could happen, much less with this volume of alterations."
The real culprit: git-filter-repo and b4 trailers
In a later message, Kees Cook identified the probable source of the error: the combined use of two tools, git-filter-repo and b4 trailers, which manipulate the commit history and trailers (tags like Signed-off-by:) in commits.
This incorrect use of the profits would have caused the automatic rewriting of thousands of commits, including replacing the author with the default value (in this case, Linus Torvalds), without Kees noticing the error at the timeKonstantin Ryabitsev, author of the b4 tool, confirmed this theory and asserted that there was no malicious intent on Cook's part. In fact, the system was already generating warnings that were ignored.
After the situation was clarified, Kees Cook's access to kernel.org was restored. As a preventive measure, it has been announced that the tool b4 will include a new security check, This will prevent the modification of commits whose authorship doesn't match the current user's identity from now on. This is intended to prevent similar errors and protect the integrity of the kernel source code.
Kees, for his part, pledged to recreate the affected branches. from individual patches and analyze in depth the steps that led to the error. Although The incident has strained relations within the team kernel development, has also highlighted the importance of using history rewriting tools with caution, especially in projects as critical as the Linux kernel.
Finally, it is worth mentioning that this incident between Linus Torvalds and Kees Cook serves as a warning about the dangers of manipulating commit history and that thanks to the rapid intervention from those responsible for kernel.org and the transparency of the process, the situation has been brought under control.
Finally, if you are interested in learning more about it, you can check the details in the following link.