With the rise of AI and humanoid robots, the word "Clanker" is being used to describe such solutions, and rightly so. In their current state, these are quite primitive, and while they can act like something resembling human intelligence, they still can't match what nature cooked up.
Now that terminology has made its way into the Linux kernel thanks to Greg Kroah-Hartman (GKH), the Linux stable kernel maintainer and the closest thing the project has to a second-in-command.
He has been quietly running what looks like an AI-assisted fuzzing tool on the kernel that lives in a branch called "clanker" on his working kernel tree. Before you ask, fuzzing is a method of automated software testing that bombards code with unexpected, malformed, or random inputs to trigger crashes, memory errors, and other misbehavior.
It is a critical line of defense for a massive codebase like Linux.
How it started
It began with the ksmbd and SMB code. GKH filed a three-patch series after running his new tooling against it, describing the motivation quite simply. He picked that code because it was easy to set up and test locally with virtual machines.
What the fuzzer flagged were potential problems specific to scenarios involving an "untrusted" client. The three fixes that came out of it addressed an EaNameLength validation gap in smb2_get_ea(), a missing bounds check that required three sub-authorities before reading sub_auth[2], and a mechToken memory leak that occurred when SPNEGO decode fails after token allocation.
GKH was very direct about the nature of the patches, telling reviewers: "please don't trust them at all and verify that I'm not just making this all up before accepting them."
These pictures show the Clanker T1000 in operation.
It does not stop there. The clanker branch has since accumulated patches across a wide range of subsystems, including USB, HID, WiFi, LoongArch, networking, and more.
Who is GKH?
If you are not well versed with the kernel world, GKH is one of the most influential people in Linux development.
He has been maintaining the stable kernel branch for quite a while now, which means every long-term support kernel that powers servers, smartphones, embedded devices, and pretty much everything else running Linux passes through his hands.
He also wrote Linux Kernel in a Nutshell back in 2006, which is freely available under a Creative Commons license. It remains one of the more approachable references for anyone trying to understand kernel configuration and building, and it is long overdue for a new edition (hint hint).
Linus has been thinking about this too
Speaking at Open Source Summit Japan last year, Linus Torvalds said the upcoming Linux Kernel Maintainer Summit will address "expanding our tooling and our policies when it comes to using AI for tooling."
He also mentioned running an internal AI experiment where the tool reviewed a merge he had objected to. The AI not only agreed with his objections but found additional issues to fix.
Linus called that a good sign, while asserting that he is "much less interested in AI for writing code" and more interested in AI as a tool for maintenance, patch checking, and code review.
AI should assist, not replace
There is an important distinction worth making here. What GKH appears to be doing here is not having AI write kernel code. The fuzzer surfaces potential bugs; a human with decades of kernel experience reviews them, writes the actual fixes, and takes responsibility for what gets submitted.
If that's the case, then this is the sensible approach, and it mirrors what other open source projects have been formalizing. LLVM, for instance, adopted a "human in the loop" AI policy earlier this year, requiring contributors to review and understand everything they submit, regardless of how it was created.
Suggested Read 📖: Greg Kroah-Hartman Bestowed With The European Open Source Award
Sourav Rudra
