Linux may drop legacy network drivers amid surge in AI-generated bug reports

Alfonso Maruccia

Posts: 2,515   +935
Staff
Editor's take: Despite not being truly "intelligent" or reliable for building entirely new software projects, generative AI tools have become extremely popular among the "vibe coding" crowd. However, Linux developers are now facing a growing problem as AI tools are increasingly surfacing issues in long-standing networking code.

The open-source community continues to question the impact of generative AI services on software development and bug reporting. "Vibe-coded" reports are becoming a growing burden for volunteers working on major software projects, starting with Linux and its extensive collection of legacy device drivers. One developer is now proposing to remove thousands of lines of code entirely to avoid spending time on AI-generated reports.

Linux developer Andrew Lunn recently submitted a series of patches to remove drivers for ancient networking devices from the open-source kernel. The drivers support ISA and PCMCIA Ethernet hardware, most of which was released "last century." In all likelihood, no current Linux users are still relying on these devices for everyday networking.

Until recently, maintaining such legacy drivers in a modern Linux kernel had not been a major issue. However, inexperienced contributors using AI tools and fuzzing techniques are now surfacing more theoretical issues in the code, forcing maintainers to revisit long-forgotten parts of the kernel to evaluate these reports.

"Fixing these old drivers make little sense, if it is not clear they have users," said Lunn.

The programmer is proposing to remove the drivers one patch at a time, making it easier to restore them if someone still owns the original hardware and is willing to maintain the code. If accepted, Lunn's patches would modify 40 files and remove more than 27,000 lines of code from the Linux kernel. Affected devices include "classic" network cards made by 3Com, Novell, Cirrus Logic, Fujitsu, and others.

Linux has traditionally provided broad support for long obsolete hardware. Just recently, the open-source kernel removed hardware emulation code required to support the ancient Intel 486 processors.

As with many areas of modern computing, AI is now complicating Linux's backward-compatibility maintenance. AI-generated reports and "vibe-coded" submissions are often viewed skeptically by developers who do not want to spend time validating hallucinated outputs from large language models, while major corporations such as Google and Microsoft are increasingly integrating AI-generated code into their workflows. Some high-profile open-source projects are also beginning to request compensation, citing the growing burden of reviewing AI-generated bug reports.

Permalink to story:

 
In all reality, you can just vibe code the open source drivers yourself if you absolutely need to use this hardware. While I hate the ter, vibe coding, being able to ask Claude or Gemini to write code for me is kinda nice. Still do some due diligence and look over the code, but just because the drivers don't come packed with the kernel doesn't mean they're unavailable
 
Sounds a lot more like bad human written code than "vibe coding" being a problem.
Tools like Copilot have helped me uncover some real bugs, but also routinely make simple statements are factually untrue, like claiming a documented parameter isn't supported by my language/version or that a given coalesce operator isn't null safe when it is and can be easily proven so by a simple one line test. At my scale it's a worthwhile tradeoff to simply ignore the one or two duds like this in an otherwise helpful batch. But if my bug tracker was emailed dozens of them every day I'd get pretty annoyed pretty quickly.
 
But if my bug tracker was emailed dozens of them every day I'd get pretty annoyed pretty quickly.
The solution is don't have code with dozens and dozens of bugs in it. Scan your own code with AI before release, because that's what everyone else is going to do anyways.
 
The solution is don't have code with dozens and dozens of bugs in it. Scan your own code with AI before release, because that's what everyone else is going to do anyways.
These are unmaintained, decades-old, but still functioning drivers, that suddenly need to be thrown away because some "researcher" successfully ran a command to do an automated "AI scan". And because of this "researcher" now a bunch of devices will be rendered obsolete.
 
The solution is don't have code with dozens and dozens of bugs in it. Scan your own code with AI before release, because that's what everyone else is going to do anyways.
Spamming maintainer's inboxes with bug notifications for 30 year old drivers almost nobody uses is not helpful.

The solution is to use those resource sot look for bugs in stuff people actually USE.
 
Spamming maintainer's inboxes with bug notifications for 30 year old drivers almost nobody uses is not helpful.

The solution is to use those resource sot look for bugs in stuff people actually USE.
Maintainers need to maintain. Old code WILL be exploited if it can be. Old code that nobody uses doesn't need to be there. Remove it from new releases and then it's no longer a problem. It's not gone for those that actually need it.

Sure, there is some legitimate spam. That is a problem. But a lot of this sounds like whiny "maintainers" not wanting to maintain their pile of human slop from decades ago. Turns out that as tech gets better, we can find more bugs faster than ever before. We can also patch them equally as fast if old geezer stubbornness doesn't prevent adoption of modern technology. I can say this as a certified old geezer with code older than my children running in the wild.
 
AI didn’t kill legacy code, it made maintaining it so annoying that maintainers are deleting the code instead.

We’ve reached a strange point where hardware from the 1990s survived decades of neglect, only to be pushed toward extinction by chatbot-generated bug reports in 2026.
 
The solution is don't have code with dozens and dozens of bugs in it. Scan your own code with AI before release, because that's what everyone else is going to do anyways.

Not a reply to my comment explaining the current technology files mistaken reports. These tools are also not deterministic, meaning your own first dozen scans may not surface an issue that someone else sees using their own model and prompts (especially likely when it's not a valid issue in the first place.)

And the code you are confidently saying has "dozens and dozens of bugs in it" had tens of millions if not hundreds of millions of users for years of daily use in its time. And the surviving form of that code was open source at the time without actionable exploits developed against it.

When the bug reporting tools are 100% accurate then maybe they are suitable for random parties to forward to maintainers. But until then, if a human is choosing to forward, or allow an agent to automatically submit, a "bug" they can barely explain themselves let alone reproduce, maybe they aren't doing anyone any favors.
 
Maintainers need to maintain. Old code WILL be exploited if it can be.
Did you pay them to maintain it? and no, if this driver was not loaded it wont be exploited. If you have such old device it is on you, really, to ensure attacker wont get to your system - and now, that person will have recompile the kernel manually. Additionally, automatically tested code showing security issues doesn't automatically mean it is exploitable at all.
 
I removed outdated drivers from Windows.
$drivers = @(
"3ware"
"ADP80XX"
"arcsas"
"b06bdrv"
...
"WinMad"
"WinVerbs"

)
 
Back