Linux Kernel Staging Area Now Rejects LLM-Generated Patches, With One Exception
Greg Kroah-Hartman announces that drivers/staging/ will automatically reject all LLM-generated patches, except genuine security fixes tested on real hardware. A red line that protects the kernel's training ground.
August 4, 2026. Greg Kroah-Hartman, maintainer of the Linux kernel’s staging subsystem and Linus Torvalds’ second-in-command, announced a new policy: all LLM-generated patches for drivers/staging/ are now automatically rejected. There is exactly one exception: genuine security fixes that the contributor has tested on the actual hardware and documented the procedure for. The reasoning is as simple as it is brutal: LLMs produce at least one-third wrong or harmful output, and staging is a training ground, not a dumpster for automated cleanups.
Staging is a school, not a bug tracker
To understand the decision, you have to understand what staging is. The drivers/staging/ directory in the Linux kernel tree holds drivers whose quality falls below mainline standards — poorly written code, misused APIs, style violations. It exists for one specific reason: to train new kernel developers.
Greg KH is explicit in his announcement: “drivers/staging/ exists PRIMARILY as a place for new kernel developers to learn how to get involved in kernel development. It contains loads of ’low hanging fruit’ with regards to code cleanups and API changes, perfect for new developers to learn the process in a safe and friendly way.”
The trade-off is that staging code is deliberately kept in bad shape. Loading a staging driver sets the TAINT_CRAP flag in the kernel — an explicit warning that this code isn’t production-ready. If the maintainers wanted to clean up staging, they could do it tomorrow with automated tools. They don’t, because staging isn’t a problem to solve — it’s a gym to preserve.
The LLM onslaught
The problem is that large language models excel at spotting low-hanging fruit. An LLM can generate, in seconds, a patch that fixes coding style violations or replaces a deprecated API in a staging driver. Dozens, then hundreds of contributors — often students or junior developers chasing their first kernel contribution — started submitting these patches.
“The recent ’onslaught’ of LLM-generated kernel patches for the drivers/staging/ subsystem” is Greg KH’s exact phrase. The volume is drowning out legitimate human contributions and gutting the subsystem’s reason for existing.
And Greg KH warns: “It is VERY obvious when people submit LLM-generated patches, so don’t think that just not disclosing the use of them will allow you to ’get away’ with anything here. The goal is for people to be able to learn, not to try to ’trick’ a maintainer. If anyone is determined to have deliberately ’tricked’ us, well, consider this your warning ahead of time.”
The threat isn’t veiled. Kernel maintainers have a long history of banning bad-faith contributors — and they can spot an LLM patch from a mile away.
The one exception: real security fixes
The policy isn’t a blanket rejection. Greg KH acknowledges that LLMs are “very good at finding suspect ’security issues’ in kernel code these days.” The tool has value — it’s just not reliable.
“Even with the best of the current and next generation tools, at least 1/3 of the results they generate are flat out wrong or harmful,” he writes. That number matters: it’s not a gut estimate, it’s the empirical return rate from the maintainer who reads every patch.
To submit an LLM-discovered security fix for staging, a contributor must:
- Have tested the patch on the actual hardware for the driver
- Describe the testing procedure in the commit message
- Be willing to defend their submission and prove it fixes a bug a user can actually hit
The hardware testing requirement is deliberately high. It mechanically filters out automated contributions — no LLM can plug in a PCI device and verify the driver still works after the patch. It also guarantees the contributor understood what they were doing. Which is exactly the point of staging.
The Schneier parallel
Greg KH closes his announcement by citing a Bruce Schneier essay: LLMs are becoming a “reasonable tool to do ’heavy lifting’ for some things,” but that heavy lifting “should only be done by those that have already properly trained their skills to know what type of lifting can be done, and in what way.”
The analogy holds. A jackhammer is an excellent tool — in the hands of a worker who knows where to strike. In the hands of someone who’s never held a hammer, it takes out the load-bearing wall. LLMs and the Linux kernel are the same.
What this means for the kernel
Greg KH’s decision technically applies only to drivers/staging/. Other subsystems — networking, memory management, filesystems — are not covered by this policy. Linus Torvalds has separately reaffirmed that the kernel “is not anti-AI” and that LLMs are tools like any other.
But the signal is strong. The staging maintainer, who is also Linus’s right hand, is drawing a clear line: automation does not replace learning. If other subsystems follow — and they likely will, given the kernel’s peer-review culture — AI contribution to Linux will be progressively confined to tasks where it adds real value without circumventing the human process.
It’s a nuanced, technical position that fits the kernel’s philosophy perfectly: tools are welcome, shortcuts are not. The kernel has survived 34 years by being conservative about what it accepts and rigorous about who gets to contribute. This policy preserves both.
Verdict
Greg KH’s position is the right one, and it should set a precedent beyond the Linux kernel:
If you contribute to an open-source project with LLM assistance, ask yourself three questions before hitting submit:
- Did I understand what the LLM produced, or did I just copy-paste?
- Did I test the change under real conditions?
- Does my contribution teach the project something — or am I just filling a quota?
The answer to the third question is what separates a developer from a script.
For open-source maintainers, the staging precedent is your reference: you have the right to reject unverified LLM contributions. You arguably have the duty to reject them if they threaten your project’s quality or educational function.
For organizations running Linux in production: this policy doesn’t affect the kernels you deploy. Staging drivers already set the TAINT_CRAP flag. The policy protects the kernel’s development pipeline, not its runtime. But it’s worth noting when your team submits upstream patches — LLM-assisted or not — that the kernel’s tolerance for unreviewed automation is now explicitly zero in at least one subsystem.