Linux Staging Tree Rejects AI-Generated Patches

Linux Puts the Brakes on the Area Most Susceptible to AI-Generated Patch Flooding

On August 3 local time, Linux kernel maintainer and Linux Foundation fellow Greg Kroah-Hartman announced that the Linux kernel’s drivers/staging/ area would no longer accept patches generated by AI models. The only exception is for genuine security vulnerability fixes, but submitters must first test them on the corresponding physical hardware and provide a detailed account of the validation process.

This is not a blanket ban on AI in the Linux kernel, nor has Linus Torvalds suddenly turned against code-generation tools. The new policy targets a very specific area—one that is also especially vulnerable to being flooded with mass-produced “contributions” from coding agents: drivers/staging/.

Here, “staging” does not refer to Git’s staging area, but to the directory in the Linux kernel source tree that houses drivers and code not yet up to mainline quality standards. It contains many outstanding issues involving coding style, API usage, error handling, and more. For years, it has also served as an entry point for new developers learning patch formatting, mailing-list collaboration, and maintainer review workflows.

Greg KH’s position is straightforward: these issues have not been left unresolved because no one is capable of fixing them all at once. They have been preserved intentionally so newcomers can learn kernel development through real changes. If they are handed over in bulk to LLMs or agents for automated processing, the patches may become tidier, but the area’s original function as a “training ground” will be hollowed out.

What Is Being Rejected Is Not the Tool, but Output With No Validation Cost for the Submitter

On the surface, this is a restriction on AI-generated code. At a deeper level, however, what the Linux kernel is really trying to curb is an asymmetric workflow: generating patches costs almost nothing, while validating them requires maintainers to invest substantial time.

A coding agent can scan thousands of files within minutes, identify unused variables, suspicious bounds checks, obsolete APIs, or code that violates style guidelines, and then generate dozens or even hundreds of patches in bulk. For submitters, the cost of clicking “confirm” and sending an email is minimal. For maintainers, every patch requires checking its context, hardware behavior, concurrency paths, error recovery, and compatibility.

Kernel code is particularly ill-suited to treating “it compiles and CI is green” as a substitute for correctness. A change to a driver may reveal problems only with a particular chip revision, bus state, power-management phase, or device hot-plug event. Static analysis can inspect control flow, and an LLM can explain the apparent intent of the code, but neither can usually observe how a real device behaves with respect to register timing, interrupts, DMA, coherency, and firmware interactions.

That is why the new policy places physical hardware testing at its core.

For ordinary application code, test environments can often be reproduced using containers, simulated data, and integration tests. For kernel drivers, the validation chain may require a discontinued network card, a particular laptop model, or even a rare USB peripheral. An agent can produce a syntactically elegant change, but it cannot use a language model’s probabilistic prediction to prove that the device will actually continue to work.

The rule therefore effectively reallocates responsibility:

• AI may help identify a problem, but it cannot replace the submitter’s responsibility to confirm that the problem actually exists;
• AI may generate a fix, but it cannot shift the testing obligation onto maintainers;
• Successful compilation is only the starting point, not evidence that a driver patch is valid;
• The exception for security fixes does not lower the bar; instead, it requires submitters to provide stronger hardware-validation evidence;
• Failing to disclose AI use does not eliminate responsibility, and deliberately misleading maintainers will further damage the submitter’s reputation.

Greg KH even warned that maintainers can usually recognize LLM-generated patches, so contributors should not expect to “slip them through” by concealing their origin. The point is not that the community has some reliable AI-text detector, but that large volumes of machine-generated patches tend to exhibit highly similar behavioral characteristics: mechanical changes, generic explanations, and a lack of hardware information. They can discuss local code at length but cannot answer why a particular device fails in a real-world scenario.

Security Patches Still Have a Path, but the Bar Is High

Greg KH has not denied AI’s value in vulnerability discovery. On the contrary, he acknowledged that current LLM tools are already capable of finding some genuine Linux kernel security issues. Over time, AI-generated security reports received by the open-source community have also begun to shift from obviously incorrect “AI slop” toward a mixture of true and false reports, some of which contain valid findings.

The problem is that improved discovery capabilities do not mean the results are already reliable. Greg’s assessment is that even the best AI tools currently available still produce output that is at least one-third completely wrong or harmful.

That rate is extremely dangerous in the context of kernel security. False positives merely consume maintainer time, but incorrect fixes can lead to three more serious consequences:

1. Fixing the symptom while leaving the root cause intact. An agent may find an out-of-bounds access without understanding object lifetimes or concurrency conditions, producing a patch that merely makes the triggering path harder to detect.
2. Introducing new regressions. Returning early to add a null-pointer check may disrupt resource cleanup, lock state, or device recovery procedures.
3. Creating a false sense of security. A patch may look reasonable, compile successfully, and come with a fluent explanation, yet the original problem was never reproduced on the relevant hardware, nor was the post-fix behavior validated.

Security issues have therefore not been categorically excluded, but submitters must provide evidence approaching the standard of an experimental record: what device, kernel version, and configuration were used; how the issue was reproduced; what happened before and after the patch; and whether regression paths were covered. Simply writing “tested by AI” is obviously meaningless, and running only generic CI is insufficient.

These requirements are a reality check for security-research agents. Truly valuable systems of the future should not merely output vulnerability descriptions and diffs. They must also be able to set up reproduction environments, generate auditable testing procedures, and integrate with laboratory hardware or remote device farms. The competitive focus for agents will shift from “writing quickly” to “providing a complete chain of evidence.”

Why drivers/staging/ Acted First

The staging drivers directory combines nearly all three conditions favored by AI automation: a large number of issues, obvious modification patterns, and patches that are easy to generate in bulk.

Tasks such as coding-style cleanup, replacement of deprecated interfaces, comment corrections, and straightforward static-analysis warnings often do not require an understanding of the entire subsystem. An agent can easily scan for a batch of candidates and apply similar changes repeatedly. If contribution counts are the only metric, this becomes an extraordinarily efficient “contribution assembly line.”

But the Linux kernel community has never evaluated contributions solely by the number of lines changed. For new developers, the value of fixing a small issue includes reading the contribution guidelines, generating a properly formatted patch, identifying the relevant maintainer, responding to review comments, and understanding the constraints behind the change. If AI compresses all these steps into a one-click submission, developers may accumulate a contribution history without developing the judgment required to maintain the kernel.

Greg KH’s decision can therefore also be understood this way: the staging area is willing to accept imperfect, human-written patches from beginners, but not seemingly perfect machine-generated patches that no human truly understands.

This is not a choice that prioritizes efficiency above all else, but it serves the kernel community’s long-term interests. What Linux lacks has never been merely correctly formatted diffs. It also needs people who can continue maintaining the code years later, explain hardware behavior, and take responsibility for regressions.

Linux Has Not Banned AI Across the Board; Responsibility Still Belongs to the Human Signer

It is important to emphasize that the new drivers/staging/ policy cannot be summarized as “Linux bans AI-generated code.” AI- or LLM-generated code has not been broadly prohibited in other parts of the kernel. Linus Torvalds has also previously treated AI as a tool, rather than something that must be completely removed from the development process.

The broader direction recently emerging within the kernel community is closer to “use is permitted, but it must be disclosed and a human must take responsibility.” An AI agent cannot add a human’s Signed-off-by tag, because that tag corresponds to the Developer Certificate of Origin (DCO) and concerns the code’s provenance, the right to submit it, and legal responsibility. Even if a patch was produced primarily by a model, the final signer must still confirm that they have the right to submit it and are willing to take responsibility for its contents.

At the same time, contributors using AI-assisted development must disclose the agent, model version, and related analysis tools they used. The purpose of provenance disclosure is not to stamp the code with an “AI-made” label, but to let reviewers understand the process through which the patch was produced, which judgments may have come from a probabilistic model, and how problems should be traced if they arise later.

This creates three progressively stricter layers of constraints:

• At the kernel-wide level: AI may be used as a tool, but the human signer assumes full responsibility;
• At the individual subsystem level: Maintainers may establish stricter rules based on review costs and the characteristics of the code;
• At the drivers/staging/ level: AI-generated patches are rejected in principle, with an exception only for security fixes validated on physical hardware.

This layered governance is more pragmatic than a blanket ban. The Linux kernel is enormous, and different directories have entirely different risks and maintenance objectives. Documentation revisions, test generation, static-analysis assistance, and low-level driver modifications should not be subject to exactly the same admission standards.

The Next Threshold for Coding Agents Is “Prove It”

Over the past two years, the main selling point of coding agents has been whether they can complete tasks independently: reading a repository, locating an issue, modifying files, running tests, and submitting a pull request. The Linux staging area’s new policy shows that, in high-risk infrastructure projects, “independent completion” is no longer the most important metric.

The real question is whether an agent can provide enough evidence for a human to assume responsibility.

This will push coding agents to address several clear shortcomings:

• Record the code, logs, and tool output underlying each step of their reasoning, rather than providing only the final patch;
• Distinguish among static inference, simulator validation, and physical hardware validation instead of conflating the three;
• Automatically generate reproducible test reports, including hardware models, firmware, kernel configurations, and failure logs;
• Stop proactively when uncertain, rather than forcing out a plausible-looking diff merely to complete the task;
• Enable human reviewers to quickly identify high-risk assumptions instead of making them read lengthy, fluent, but vague explanations.

From an industry perspective, this rule is not bad news for coding agents. It merely punctures an overly optimistic metric: a patch compiling successfully does not mean the agent is capable of assuming software-engineering responsibility.

In an ordinary business application repository, a bad patch may trigger a rollback. In a Linux driver, an incorrect patch may cause device failure, data corruption, a system crash, or even create a new attack surface. The closer AI gets to low-level infrastructure, the less its value can be measured solely by generation speed. The costs of human review, false-positive handling, and hardware validation must also be subtracted.

Conclusion: AI Can Write the Code, but Merge Eligibility Still Depends on Humans and Hardware

The Linux staging area’s rejection of AI-generated patches signals that the open-source community is beginning to turn debates over attitudes toward “AI-assisted development” into concrete admission rules.

It does not deny models’ ability to discover vulnerabilities, understand code, or generate fixes, nor does it require developers to return to an entirely manual era. What it rejects is a workflow in which machine-generated results are simply dumped on maintainers, leaving the community to bear the cost of validation.

In the short term, this will reduce the number of correctly formatted but low-value patches and eliminate a shortcut for people seeking to use agents to rapidly build a record of kernel contributions. In the long term, it points coding agents toward a clearer product direction: instead of continuing to pursue the generation of more diffs in a single pass, they should make provenance disclosure, responsibility confirmation, reproducible testing, and physical hardware validation standard capabilities.

AI can help humans write kernel code, but it still cannot sign for responsibility, nor can it prove on behalf of a physical network card that a driver genuinely works. In Linux, at least, the final gate before a patch is merged remains guarded jointly by humans and hardware.

References

• ITHome: Linux Staging Area Does Not Welcome AI-Generated Patches; Security Fixes Must Be Validated Through Physical Hardware Testing — Reports on Greg Kroah-Hartman’s new policy for drivers/staging/ and the conditions governing exceptions for security fixes.
• Zhihu: Surrounded by AI Slop—How Linux Is Responding — Reviews the background to the Linux kernel community’s handling of AI-generated code, quality review, and responsibility.