Loading story…
Linux kernel maintainer Greg Kroah-Hartman said the drivers/staging subsystem will reject LLM-generated patches except for genuine security fixes that have been validated on real hardware, after maintainers faced an "onslaught" of AI-produced submissions. The change is meant to preserve staging as a training ground for human developers rather than a destination for automated cleanup work, while still allowing narrowly scoped AI-assisted security fixes when contributors can test and defend them.
The policy lands as new research highlighted uneven results from using large language models to remediate software flaws: some generated patches were effective, but others changed program behavior, failed to fix the original vulnerability, or introduced new weaknesses. Researchers examining AI-generated vulnerability fixes found outcomes depended on prompt quality, software complexity, programming language, and the reviewer’s expertise, reinforcing broader warnings that AI can assist with coding and bug discovery but still requires careful human validation before security patches are accepted.
Mallory correlates global threat intelligence with your attack surface — know if you’re exposed before adversaries strike.
2 events from the most recent confirmed update back to the earliest known activity.
On 2026-08-04, Greg Kroah-Hartman announced a new policy for the Linux kernel's drivers/staging subsystem to automatically reject LLM-generated patches. The only exception is for genuine security fixes that have been validated on real hardware and can be defended by the submitter.
Keith Hoodlet and his team said their research on LLM-generated vulnerability patches, along with its toolset and data, is planned for release at Black Hat on August 6. The work examines when model-generated patches are effective and when they alter behavior, fail to fix flaws, or introduce new vulnerabilities.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
3 references tracked. Mallory keeps watching after this page renders.
phoronix.com
Open sourcescworld.com
Open sourceschneier.com
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Research from 1Password’s Off-by-1 Labs found that frontier LLMs frequently produced unsafe or incomplete fixes when asked to patch newly disclosed software vulnerabilities. In a study of **6,080 AI-generated patches** for six recent open-source CVEs, only **26.0%** fully resolved the issue without materially changing application behavior; **20.1%** fixed the flaw but altered behavior, while **53.9%** either failed to remediate the bug, introduced a new vulnerability, or both. The researchers said many outputs looked plausible and even passed tests, yet still left exploitable paths open or created fresh defects; in one `freenginx` case study, 114 patches judged to close the original flaw all introduced a new problem. 1Password said expert validation remains necessary and released tooling, datasets, and a paper to support large-scale patch evaluation. The findings coincided with a tougher stance from Linux wireless maintainer **Johannes Berg**, who said AI/LLM-generated patches for that subsystem will be ignored unless a brief review shows they are obviously correct. Berg argued that such fixes often make narrow local changes without adequately accounting for code semantics, architecture, error ordering, or long-term maintainability. Although it was later clarified that `syzbot` AI-assisted patches are pre-reviewed by humans rather than automatically submitted, AI-assisted patch submissions from `syzbot` are being disabled for the Linux wireless codebase, underscoring growing concern that machine-generated fixes can add risk instead of removing it.
Aug 7, 2026
GNOME's security team changed its vulnerability-handling process by cutting the default disclosure deadline for new reports from 90 days to 30 days and by declining to forward reports to projects that prohibit AI-generated submissions. The policy shift, discussed widely on the `oss-sec` mailing list, reflects the view that most embargoed fixes are completed within the first month and that AI-assisted reporting has become common enough that many submissions now contain at least some machine-generated material. Participants also noted that some projects, including the Linux kernel, have moved away from embargoes for AI-generated reports because such findings can be easily reproduced and redistributed. The change triggered a broader dispute over open-source security governance, with maintainers arguing that low-quality, verbose, or impractical AI-assisted reports are consuming scarce triage capacity and pushing burnout onto already overstretched teams. Mailing-list contributors said many externally submitted bugs are real defects but not necessarily exploitable vulnerabilities, while others warned that rejecting accurate reports could still increase user risk. The debate expanded to the Linux Foundation's **Akrites** initiative, described by critics as an attempt to coordinate AI-era vulnerability response and potentially serve as a "maintainer of last resort" for abandoned critical packages, though others stressed that such a role would not override project ownership or maintainer authority.
Aug 6, 2026
Security researchers and industry commentators warned that AI is rapidly accelerating patch analysis and vulnerability discovery, making it easier to extract exploit-relevant details from public fixes before many organizations can remediate. Reporting on recent research highlighted how large language models and automated patch-diffing can identify patched executables, vulnerable functions, and likely root causes from vendor updates, while Linux-focused analysis said similar techniques can infer affected components and even help reproduce proof-of-concept conditions from public patches. Examples cited include Akamai’s **PatchDiff-AI** work on Windows updates and **K-Repro** research that reproduced dozens of `KernelCTF` vulnerabilities from patch data. The coverage said defenders are struggling with incomplete vulnerability intelligence and weak automation inputs, especially when advisories lack timely, machine-readable metadata. One example involved **CVE-2026-7473** in **Arista EOS**, which was reportedly exploited in the wild but did not appear in public CVE databases for about a month after Arista published its advisory; Arista also issued configuration-based mitigations rather than a software patch, limiting the usefulness of version-only scanners. The reports argued that organizations need stronger configuration monitoring, intrusion detection, threat hunting, and better vendor support for structured advisory formats such as **CSAF** to keep pace with AI-enabled attackers.
Aug 1, 2026