Linux may be ending support for older network drivers due to influx of false AI-generated bug reports — maintenance has become too burdensome for old largely-unused systems

Linux penguins — Linux patches to remove ancient network drivers from kernel source tree (Image credit: Getty Images)

The Linux kernel community is currently debating a significant proposal that could see countless legacy network drivers purged from the mainline source code to combat an unsustainable surge in AI-driven bug reports. This development follows a patch series submitted by OG developer Andrew Lunn to the netdev mailing list earlier this week.

Maintaining support for old hardware has always been a “thing” for Linux. However, thanks to AI-wielding “detectives,” the sheer number of reports is forcing a shift in the kernel’s long-standing philosophy. Developers must now choose between addressing countless low-quality or hallucinated reports on systems no one uses or focusing their limited time on modern, high-impact subsystems.

Andrew Lunn argued that while support for aging ISA and PCMCIA-era hardware was once a low-maintenance endeavor, it has recently become a disproportionate burden due to newbies using AI and fuzzers to uncover theoretical defects in code that likely have no remaining active users.

Latest Videos From

"These old drivers have not been much of a maintenance burden until recently,” writes Lunn. “Now there are more newbies are using AI and fuzzers to find issues, resulting in more work for Maintainers. Fixing these old drivers makes little sense if it is not clear they have users.”

Linux patches to remove ancient netwrok drivers from kernel source tree — Linux patches to remove ancient network drivers from kernel source tree (Image credit: Linux Kernel Community)

Lunn notes that many of the Ethernet devices date to the late 1900s and feature ISA or PCMCIA interfaces (although there are a few that debuted between 2001 and 2002). If accepted, Lunn's proposal would remove specific drivers from 3Com, AMD, SMSC, Cirrus Logic, Fujitsu, Xircom, and 8390-based hardware families, eliminating approximately 27,646 lines of code from the kernel source tree.

More importantly, rather than nuking support all at once, Linux would handle the removal one patch at a time, meaning a user could restore any of these drivers if they still depend on them and are willing to step in as a maintainer. This approach would ensure that legacy systems are not permanently locked out, but no longer impose an ongoing maintenance burden by default.

Follow Tom's Hardware on Google News, or add us as a preferred source, to get our latest news, analysis, & reviews in your feeds.

Etiido Uko is a news contributor for Tom's Hardware covering the latest updates in big tech and the PC industry. He is a mechanical engineer and senior technical writer with over nine years of experience in documentation and reporting. He is deeply passionate about all things engineering and technology, and is an expert in gadgets, manufacturing, robotics, automotive, and aerospace.

7 Comments Comment from the forums

ekio

The journalist didn’t understand the situation properly here.

The reports are not false at all, AI finds real bug and vulnerabilities, but at a too fast pace for maintainers to keep up with tickets.

Maintainers will drop some obsolete drivers with vulnerabilities found by AI because too much work, not enough users.
Reply
coolitic

ekio said:
The journalist didn’t understand the situation properly here.

The reports are not false at all, AI finds real bug and vulnerabilities, but at a too fast pace for maintainers to keep up with tickets.

Maintainers will drop some obsolete drivers with vulnerabilities found by AI because too much work, not enough users.
No, it's certainly both. And likely more hallucinations or very theoretical edge-cases than anything else.
Reply
LabRat 891

So, what I'm getting out of this is:
Don't bother switching to Linux, it's well on its way to being maintained like a MSFT product.

"Too many bugs, too old of hardware, too hard. Unsupported!"
Reply
Terry Lambert

Just make the modules loadable, make them not loaded by default, and make them warn when they are loaded explicitly, and require acknowledgment of the warning to allow them to be loaded.

“This driver has AI reported bugs which may compromise your security, or may just be the AI hallucinating again. “
If there’s an omnibus bug report that somebody wants to maintain that links to individual bugs on a driver by driver basis, which have been reported, so that they can take care of the bugs to get rid of the warning, and get rid of the forced acknowledgment of the warning, then they can go ahead and send patches.

Otherwise, they can continue to use the driver, but it’s going to pester them every time they do so.

Much better than simply dropping support for the driver.

If the default policy is dropping support for the driver, then all I have to do is generate a bunch of fake AI bug reports anytime I want my competitors driver out of the Linux kernel, and somebody will obligingly pull the driver.

If the new jerk response is pulling a driver anytime, there are too many bug reports, then it’s really easy to abuse that process, which makes the bug reporting process an tax surface on the Linux community at large.
Reply
wakuwaku

ekio said:
The journalist didn’t understand the situation properly here.

The reports are not false at all, AI finds real bug and vulnerabilities, but at a too fast pace for maintainers to keep up with tickets.

Maintainers will drop some obsolete drivers with vulnerabilities found by AI because too much work, not enough users.
Your word is no better than any Tom's writer. Zero Citations, Zero indication of reading sources and/or citations, just pure: "What I write must be right because I am always right!"

Sure go ahead with your hallucinations.
Reply
thesyndrome

Terry Lambert said:
Just make the modules loadable, make them not loaded by default, and make them warn when they are loaded explicitly, and require acknowledgment of the warning to allow them to be loaded.

“This driver has AI reported bugs which may compromise your security, or may just be the AI hallucinating again. “
If there’s an omnibus bug report that somebody wants to maintain that links to individual bugs on a driver by driver basis, which have been reported, so that they can take care of the bugs to get rid of the warning, and get rid of the forced acknowledgment of the warning, then they can go ahead and send patches.

Otherwise, they can continue to use the driver, but it’s going to pester them every time they do so.

Much better than simply dropping support for the driver.

If the default policy is dropping support for the driver, then all I have to do is generate a bunch of fake AI bug reports anytime I want my competitors driver out of the Linux kernel, and somebody will obligingly pull the driver.

If the new jerk response is pulling a driver anytime, there are too many bug reports, then it’s really easy to abuse that process, which makes the bug reporting process an tax surface on the Linux community at large.
Agreed, just include it as an option during install, or something tucked away that can be activated through the terminal after install (or both) and give explicit warnings about AI's flagging it's older systems as bugs if you choose to enable it
Reply
ekio

wakuwaku said:
Your word is no better than any Tom's writer. Zero Citations, Zero indication of reading sources and/or citations, just pure: "What I write must be right because I am always right!"

Sure go ahead with your hallucinations.
What I can tell you, is that with AI improvements in the field of security, this situation will get much worse.

New models will find hundred if not thousands of exploits and the result will be more abandoned obsolete drivers fullof holes and that’s where Linus Torvalds was a genius once again enabling Rust for the Linux kernel. Rust drivers are hundreds of times less exposed, making the AI security agent situation bareable in the future.
Reply

Show more comments