Kernel code removals driven by LLM-created security reports [LWN.net]

There are a number of ongoing efforts to remove kernel code, mostly from the networking subsystem, as an alternative to dealing with the increase in security-bug reports from large language models. The proposed removals include ISA and PCMCIA Ethernet drivers, a pair of PCI drivers, the ax25 and amateur radio subsystem, the ATM protocols and drivers, and the ISDN subsystem.

Remove the amateur radio (AX.25, NET/ROM, ROSE) protocol implementation and all associated hamradio device drivers from the kernel tree. This set of protocols has long been a huge bug/syzbot magnet, and since nobody stepped up to help us deal with the influx of the AI-generated bug reports we need to move it out of tree to protect our sanity.

to post comments

Slightly Ambiguous Title

Posted Apr 22, 2026 7:01 UTC (Wed) by sneela (subscriber, #180826) [Link] (23 responses)

The title sort of reads like the LLM-created security reports _helped_ remove the kernel code, whereas it's the problem of increasing number of LLM-created security reports which drove the kernel code being removed.

Slightly Ambiguous Title

Posted Apr 22, 2026 8:19 UTC (Wed) by taladar (subscriber, #68407) [Link] (22 responses)

No, the problem is all the unmaintained code in large projects like the kernel which has been pretending to be maintained by being part of some large project instead of being a separate project where the unmaintained status would have been visible years ago.

Slightly Ambiguous Title

Posted Apr 22, 2026 9:42 UTC (Wed) by aragilar (subscriber, #122569) [Link] (21 responses)

Is it (in every case) unmaintained? Looking through the patches it seems to be older hardware, where I'd expect the only changes to be from kernel infrastructure evolution, not new features. https://lwn.net/ml/all/e056d348-4560-4df3-85c4-e29393b004... I think highlights the problem as junk reports/code, and so reducing the number of things to review seems to be aim, even if such devices are still in use. Leaving people to be stuck on old kernels isn't great.

Slightly Ambiguous Title

Posted Apr 22, 2026 12:44 UTC (Wed) by NAR (subscriber, #1313) [Link] (20 responses)

"Leaving people to be stuck on old kernels isn't great."

Can newer kernels boot on hardware that still has PCMCIA Ethernet cards? I mean software (including the Linux kernel) tend to require more and more resources over time and I'm not sure that a laptop from 1998 is able to run a Linux 7.0-based system anyway... Might as well stick to a kernel from that age and if security is required (who will want to pown that machine?), one can always put a firewall in front of it...

Slightly Ambiguous Title

Posted Apr 22, 2026 12:51 UTC (Wed) by pizza (subscriber, #46) [Link] (18 responses)

> Can newer kernels boot on hardware that still has PCMCIA Ethernet cards?

Given that PCI adapters with PCMCIA slots exist, the answer to that is an emphatic YES.

Slightly Ambiguous Title

Posted Apr 22, 2026 13:23 UTC (Wed) by antoinealb (subscriber, #124877) [Link] (17 responses)

But if your system setup is i686 or later CPU -> PCI -> PCMIA -> Ethernet card, is there a real use case compared to just CPU -> PCI -> Ethernet ? I get the desire to do retro computing hobby, but does it make sense to incur this hobby cost on every maintainer of the kernel ?

Slightly Ambiguous Title

Posted Apr 22, 2026 13:53 UTC (Wed) by pizza (subscriber, #46) [Link] (16 responses)

> But if your system setup is i686 or later CPU -> PCI -> PCMIA -> Ethernet card, is there a real use case compared to just CPU -> PCI -> Ethernet

Not for "ethernet" per se [1], but there were many, many, many types of PCMCIA (and Cardbus) cards produced for different applications. Including interfacing to industrial equipment whose lifespan is measured in decades.

[1] Unless you're talking about something other than XX-BASE-T.

Slightly Ambiguous Title

Posted Apr 22, 2026 14:27 UTC (Wed) by paravoid (subscriber, #32869) [Link] (15 responses)

"Industrial equipment whose lifespan is measured in decades" is typically priced at >= six figures. Perhaps the manufacturer of said equipment can afford -or incorporate into their price- the costs to maintain the software for the entire lifecycle of their hardware. If they've gone defunct, presumably there is a market for someone to be paid to continue to maintain e.g. PCMCIA for them.

AIUI the problem here is not that ISA or PCMCIA are old - it's that they have not been adequately maintained and kept up to ever-evolving coding standards and bug reports. Expecting a third party (often: a volunteer) to continue to incur the cost of maintaining software for a another company's industrial equipment for free, is not a reasonable ask IMHO.

Slightly Ambiguous Title

Posted Apr 22, 2026 14:53 UTC (Wed) by pizza (subscriber, #46) [Link] (10 responses)

> "Industrial equipment whose lifespan is measured in decades" is typically priced at >= six figures.

"six figures" is the _low_ end of that price range. Which is why it stays in service approximately forever.

> Perhaps the manufacturer of said equipment can afford -or incorporate into their price- the costs to maintain the software for the entire lifecycle of their hardware.

It is quite common for equipment to be in use long after its manufacturer has ceased to exist.

> AIUI the problem here is not that ISA or PCMCIA are old - it's that they have not been adequately maintained and kept up to ever-evolving coding standards and bug reports. Expecting a third party (often: a volunteer) to continue to incur the cost of maintaining software for a another company's industrial equipment for free, is not a reasonable ask IMHO.

Don't forget that volunteers probably wrote that software in the first place. (Note that I'm lumping "employed by a company with that equipment" into that bucket) And it's not a reasonable ask to ask them to maintain stuff indefinitely either.

If your argument is that the _current users_ of this equipment should step up to maintain this stuff in upstream linux, that's at least a reasonable argument. But what's going to happen in practice is that those users won't even know that upstream Linux is dropping these features until a couple years after the fact, ie when they pick up latest round of LTS distros.

(FWIW I think it is quite reasonable to completely eject ISA support now that support for 486s are also removed. I think the last new motherboard I saw with ISA slots was during the Socket 370 era, and that ended over twenty years ago)

Slightly Ambiguous Title

Posted Apr 22, 2026 15:16 UTC (Wed) by paravoid (subscriber, #32869) [Link] (1 responses)

>> "Industrial equipment whose lifespan is measured in decades" is typically priced at >= six figures.
>
> "six figures" is the _low_ end of that price range. Which is why it stays in service approximately forever.

Hence ">=" six :)

>> Perhaps the manufacturer of said equipment can afford -or incorporate into their price- the costs to maintain the software for the entire lifecycle of their hardware.
>
> It is quite common for equipment to be in use long after its manufacturer has ceased to exist.

Hence my "If they've gone defunct, ..." sentence :)

> If your argument is that the _current users_ of this equipment should step up to maintain this stuff in upstream linux, that's at least a reasonable argument.

It was rather that these current (end) users can seek and pay vendors in the Linux ecosystem for maintenance, and rely on their vendors to know if and when they are going to be affected by whatever upstream change and when, and get ahead of it.

What is the alternative? Hoping that your million-dollar equipment that was procured by a vendor that has since ceased to exist, and for which you pay no recurring maintenance costs for its software, will continue to function indefinitely and with the newest releases of software (like e.g. Linux 7.1), authored decades after the hardware was manufactured and procured?

Slightly Ambiguous Title

Posted Apr 22, 2026 15:29 UTC (Wed) by pizza (subscriber, #46) [Link]

> What is the alternative? Hoping that your million-dollar equipment that was procured by a vendor that has since ceased to exist, and for which you pay no recurring maintenance costs for its software, will continue to function indefinitely and with the newest releases of software (like e.g. Linux 7.1), authored decades after the hardware was manufactured and procured?

...yes, because that's worked so far? (In other words, "business as usual")

Slightly Ambiguous Title

Posted Apr 22, 2026 16:29 UTC (Wed) by rgmoore (✭ supporter ✭, #75) [Link] (6 responses)

If your argument is that the _current users_ of this equipment should step up to maintain this stuff in upstream linux, that's at least a reasonable argument. But what's going to happen in practice is that those users won't even know that upstream Linux is dropping these features until a couple years after the fact, ie when they pick up latest round of LTS distros.

I would argue that puts the onus on the LTS distros to do the work. They have the technical skill, financial wherewithal, and commercial motivation to do the work. If the kernel developers don't want to keep this kind of specialty stuff in mainline- and I can definitely see the argument for getting rid of it- somebody like RedHat could maintain it out of tree for their customers who depend on it. I guess it could also be maintained out of tree by a consortium of industrial users who depend on the code.

Slightly Ambiguous Title

Posted Apr 22, 2026 16:45 UTC (Wed) by paravoid (subscriber, #32869) [Link]

> I would argue that puts the onus on the LTS distros to do the work. They have the technical skill, financial wherewithal, and commercial motivation to do the work. If the kernel developers don't want to keep this kind of specialty stuff in mainline- and I can definitely see the argument for getting rid of it- somebody like RedHat could maintain it out of tree for their customers who depend on it

s/LTS/Enterprise/ to nitpick but yes, otherwise agreed. In fact this market exists and this regularly happens. It's just that it's usually the case that this support happens through the long-term maintenance of old code (kernel or userspace), not through the maintenance of antiquated subsystems in bleeding edge kernels. IOW, there is little (if any at all) market demand for running Linux 7.1+ on hardware that shipped 35 years ago.

> I guess it could also be maintained out of tree by a consortium of industrial users who depend on the code.

With regards to the kernel specifically, are you aware of https://cip-project.org/ ?

Slightly Ambiguous Title

Posted Apr 22, 2026 17:02 UTC (Wed) by tuna (guest, #44480) [Link] (3 responses)

Why not maintain it in the main Linux tree managed by Linus Thorvalds?

Slightly Ambiguous Title

Posted Apr 23, 2026 18:46 UTC (Thu) by smurf (subscriber, #17840) [Link] (2 responses)

Because nobody is doing that work, in fact has not been doing it for a decade or two.

NB: Torvalds.

Slightly Ambiguous Title

Posted Apr 25, 2026 18:51 UTC (Sat) by tuna (guest, #44480) [Link] (1 responses)

So the problem is not "where" the work should be done, it is that nobody is doing it or even wants to do it?

Maintaining old code

Posted Apr 27, 2026 9:52 UTC (Mon) by farnz (subscriber, #17727) [Link]

The core is that Linus is quite relaxed about low-problem code, even if it's unmaintained. As a result, there's a decent chunk of the kernel where nobody is doing the work, but not a problem because it's trivial to keep it up to date with core API changes via mechanical changes.

There's only one tool Linus has to find people using the code and get them to step up to do the maintenance work - dump it out of the kernel, and wait for a user to appear who can be convinced to maintain the code they care about.

Slightly Ambiguous Title

Posted Apr 23, 2026 9:17 UTC (Thu) by pbonzini (subscriber, #60935) [Link]

If Red Hat customers were interested in PCMCIA support, the company would just maintain it upstream. However, RHEL kernel stopped enabling CONFIG_PCMCIA with RHEL7 based on a quick grep.

Slightly Ambiguous Title

Posted Apr 22, 2026 17:17 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

> (FWIW I think it is quite reasonable to completely eject ISA support now that support for 486s are also removed. I think the last new motherboard I saw with ISA slots was during the Socket 370 era, and that ended over twenty years ago)

Not quite. I used an industrial motherboard with an ISA slot in 2008 to interface with a telephony switch (an analog switch, not digital).

Slightly Ambiguous Title

Posted Apr 23, 2026 13:49 UTC (Thu) by nim-nim (subscriber, #34454) [Link] (3 responses)

> Perhaps the manufacturer of said equipment can afford -or incorporate into their price- the costs to maintain the software for the entire lifecycle of their hardware.

Urban legend says that some of the factories Thatcher closed were still using tooling from the *beginning* of the industrial revolution. That’s how long industrial lifecycle can be. Longer than the lifetime of some countries.

A lot of this equipment is expensive because it is manufactured in very small numbers. The manufacturer sets up an engineering team, manufactures and sells a small number of units, stockpiles enough spares for the reasonable selling period, then disbands the engineering team and production line and (if the product paid for itself) restarts with a new product. The buyer buys a even smaller number of units, stockpiles spares while they are available, deploys the hardware, then expects the result to run forever, and reallocates the humans to some other deployment.

Neither manufacturer nor buyer is organised for long term support or short replacement cycles, that would make no economic sense, the runs are too small and too expensive and there is no economic sense on making them bigger. The market is too small and by the time the original small number of units has been sold the tech has moved on they are no longer competitive with newer products.

How do you fit long term software maintenance in there? You could isolate it in some form of standardised “compute” module but good luck making everyone agree on this module specs. And BTW that’s what the automotive industry tried to do and the resulting mashup of modules was uncompetitive with integrated offerings.

Slightly Ambiguous Title

Posted Apr 23, 2026 16:23 UTC (Thu) by rgmoore (✭ supporter ✭, #75) [Link] (2 responses)

The buyer buys a even smaller number of units, stockpiles spares while they are available, deploys the hardware, then expects the result to run forever, and reallocates the humans to some other deployment.

There's also support in the form of a bunch of salvage stores, small-scale machine shops, and the like that exist to source replacement parts once the initial stock of spares runs out. What those manufacturers need, and what computer people need to learn to provide, is the computer equivalent. That could be some combination of old hardware salvagers, emulators to keep old software running, and small-scale hardware shops that can build replacements for antique boards. Also security people who can ensure all this antique stuff is protected from criminals even if it needs to be networked to function properly.

Slightly Ambiguous Title

Posted Apr 23, 2026 18:58 UTC (Thu) by kschendel (subscriber, #20465) [Link] (1 responses)

The problem of maintaining old, specialized, or bespoke software is complicated by the fact that the source is all too often not available. Hardware bits can be fabricated, assuming that one has a more or less undamaged original to copy, and assuming that the material is still available in some form. (i.e. not some weird alloy that was exotic in its time, but has been superseded by new stuff that is "better" but behaves differently in some critical (to the use case) way.) Both customers and vendors of such hardware accept this as a tacit assumption, probably along with the assumption that as long as the vendor is around, it's easier and cheaper for the customer to go to the vendor for spares / replacement parts, rather than try to bypass them via hardware reconstruction.

Software on the other hand was, and I guess all too often still is, considered company proprietary secret sauce. It's as if a supplier made a critical part out of (say) a supplier-invented plastic with properties sufficiently unlike any other, and the formula died with the supplier. It''s hard, for me, to imagine something like that in the material world. In the software world, it's the norm.

I recall that some 6 years ago, a company that I had consulted with 15 years before that (!), called in a panic. They were using some package that had been customized for them (not by me), and that they had expected to stop using well before the panic call. They had indeed stopped using it in production, but alas, they had to extract some archival data for legal reasons. They had the underlying data but producing the required report would have basically needed the application to run ... which they couldn't, as the license had timed out, and they didn't have any source code! The vendor no longer existed. I remember spending a couple of days (remunerative for me, painful for them) generating a machine instruction patch to the application binary that allowed them to use it long enough to get the legally required "stuff". I can't imagine the pain if they had had to do anything more complicated than "just let us run the thing for a moment."

So the problem as I see it is twofold. One, customers need to demand long term access to source in some way; escrow, perhaps. Two, vendors need to reconcile themselves that in order to make a sale, they have to provide for some way for customers to make software fixes even when they the vendor aren't around any more. This of course will be easily accomplished. (yeah right)

Software pain points for long-term equipment

Posted Apr 24, 2026 9:01 UTC (Fri) by farnz (subscriber, #17727) [Link]

The other bit of pain that shows up again and again is that hardware is relatively simple stuff in an extremely complex environment; we exploit the relatively simple environment software faces (since it's a virtual world created by the hardware) to allow us to spend our thinking budget on making the software much more complex.

This shows up when you're trying to replace a 1990s product - your total hardware design is an order of magnitude smaller as digital files (schematics, PCB layouts, drilling decisions, component choices etc) than the software source code, even when both are compressed with state of the art compressors. And that drives a new problem - we don't build anything completely in isolation, and even if you retained the source for your part of the software, there's a good chance that you bought something in and didn't retain source code. For example, there's systems out there built on top of Windows Embedded - and if the part you need to fix is in the Windows Embedded layer, you're not going to have source, and it'll cost a lot, too.

Slightly Ambiguous Title

Posted Apr 23, 2026 6:41 UTC (Thu) by aragilar (subscriber, #122569) [Link]

It would seem at least one of the drivers mentioned is used by people on modern kernels, see the linked mailing list threads, that's what I looked at.

I prefer bogus Amateur Radio than no driver

Posted Apr 22, 2026 7:12 UTC (Wed) by Alterego (guest, #55989) [Link] (4 responses)

Amateur radio is useful in many (far away isolated) places, and fun.
I guess this will never be a place were T$ company will invest.

Should we allow "AI" to tell us what to do, or should we keep our human free (as in speech) fun stuff, no matter it is bogus or not.

I prefer bogus Amateur Radio than no driver

Posted Apr 22, 2026 7:27 UTC (Wed) by Funcan (guest, #44209) [Link]

This is less AI telling us what to do, and more AI pwning systems. Rather different thing.

Does Amateur Radio really need drivers?

Posted Apr 22, 2026 9:18 UTC (Wed) by arnout (subscriber, #94240) [Link] (1 responses)

Amateur Radio absolutely has a place in the free software world, but does it really need to be in the kernel? I've played with GNURadio and it works perfectly fine in userspace, why should it be different for amateur radio?

Does Amateur Radio really need drivers?

Posted Apr 23, 2026 8:10 UTC (Thu) by danielthompson (subscriber, #97243) [Link]

That is exactly was has been reported in the mail thread, "Consensus for a userspace implementation is what folks on linux-hams
seem to be converging on."

For a little more detail see:
https://lwn.net/ml/all/CAEoi9W6ZRw6aEh62Xbgkg-TW8URHbVp6d...

I prefer bogus Amateur Radio than no driver

Posted Apr 22, 2026 10:36 UTC (Wed) by tao (subscriber, #17563) [Link]

If you're willing to maintain all of those drivers and fix the bugs then I'm sure they can be kept in-tree. But just because they are functional doesn't mean they're secure. Finding security issues and reporting them isn't some AI conspiracy. But no matter in what subsystem issues are found they need to be fixed. If there is no maintainer willing to do so, then (especially when there are viable user-space solutions) the safest bet is to remove such drivers.

If they generate bug reports, they must also generate fixes

Posted Apr 22, 2026 7:55 UTC (Wed) by jafd (subscriber, #129642) [Link] (8 responses)

I would demand that LLMs used to generate bug reports MUST also generate patches to fix those, on pain of being ignored.

If they generate bug reports, they must also generate fixes

Posted Apr 22, 2026 8:11 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (6 responses)

The bug exists independent of whether a patch is provided or not. This is brutally unfair on all the humans involved in developing the codebase and also ignoring the report is unfair on all the humans whose privacy and security depend on the codebase.

If they generate bug reports, they must also generate fixes

Posted Apr 22, 2026 8:37 UTC (Wed) by ballombe (subscriber, #9523) [Link] (5 responses)

Removing support for HAM radio will not increase the security of anyone.

If they generate bug reports, they must also generate fixes

Posted Apr 22, 2026 8:43 UTC (Wed) by taladar (subscriber, #68407) [Link] (3 responses)

It will increase the security of HAM radio operators who previously thought they could expect their systems to be secure despite being connected to a system that the entire world can talk to.

As well as the security of anyone else on the same private network as they are.

Honestly, this reminds me of the horrible security situation of printer Fax stacks that have been used to compromised quite a few networks in a route not on a lot of people's radar.

If they generate bug reports, they must also generate fixes

Posted Apr 22, 2026 9:31 UTC (Wed) by darmengod (subscriber, #130659) [Link] (1 responses)

We will increase the security of HAM radio operators by removing their ability to operate their HAM radio.

If they generate bug reports, they must also generate fixes

Posted Apr 22, 2026 9:59 UTC (Wed) by farnz (subscriber, #17727) [Link]

You're not removing the ability to operate a ham radio - this doesn't remove CAT (serial port) or soundcard support, nor does it prevent userspace applications like direwolf, WSJT-X, nor are you preventing AGWPE (the current state of the art for AX.25 applications) from being used.

If they generate bug reports, they must also generate fixes

Posted Apr 22, 2026 11:49 UTC (Wed) by pizza (subscriber, #46) [Link]

> It will increase the security of HAM radio operators who previously thought they could expect their systems to be secure despite being connected to a system that the entire world can talk to.

Only in the sense that a brick is more "secure" than a working radio.

If they generate bug reports, they must also generate fixes

Posted Apr 22, 2026 13:17 UTC (Wed) by dezgeg (guest, #92243) [Link]

That depends on whether the vulnerable codepath requires actually having the affected hardware, or whether just having the module loaded is enough.

If they generate bug reports, they must also generate fixes

Posted Apr 22, 2026 14:42 UTC (Wed) by ferringb (subscriber, #20752) [Link]

> I would demand that LLMs used to generate bug reports MUST also generate patches to fix those, on pain of being ignored.

You might as well demand the same thing of all source analysis tools; bias against AI for doing it better than hand crafted stuff like syzbot (or just brute force fuzzers) is just that, bias.

The bugs and vulns will exist whether you like the tooling used or not, and if it's getting this easy to flush them out, it's stupid not to take the reports once the signal quality is acceptable.

Security audits for ISA card drivers. What's the point? What's the goal here?

Posted Apr 22, 2026 7:56 UTC (Wed) by darmengod (subscriber, #130659) [Link] (10 responses)

Let's be real, one should expect quality (and we're focusing on security here) from software to be correlated with how "important" such software is. I do not expect the same amount of hardening against malicious actors from an amateur radio drver than I do from the Linux kernel's TCP stack -- indeed, if you ask me, that would be a *huge waste of effort*. The standard for that sort of systems is that they work correctly at all, not that they're "secure".

It raises the question, then: why expend the effort on looking for *security* bugs there? And with what we've been seeing for months, well the answer is because of course you're going to find them there! All software has bugs, and the less widely-used it is -- the less tested it is -- the more you're going to find, and nevermind the actual positive effect of finding and reporting them. It's just boosting numbers.

There's definitely merit in removing such legacy code once the maintenance burden exceeds the benefit it provides, but that's not what we're talking about here.

Security audits for ISA card drivers. What's the point? What's the goal here?

Posted Apr 22, 2026 8:22 UTC (Wed) by taladar (subscriber, #68407) [Link] (7 responses)

Actually I would expect the effort focused on security to depend on how easy it is for others to inject data that is then processed by that code so actually something handling data from a radio antenna where literally anyone could send data should be more hardened than most other code.

Security audits for ISA card drivers. What's the point? What's the goal here?

Posted Apr 22, 2026 9:25 UTC (Wed) by farnz (subscriber, #17727) [Link] (6 responses)

The radio antenna is less of a concern - more of a concern is that if I can load the modules on a system without ham radio gear installed (e.g. via protocol module autoloading), I can exploit bugs in them that allow me to get privileged access I should not have.

As an aside, if someone's affected by this, direwolf does a lot of what the ham radio stack used to do with hardware TNCs and the like in software, using your radio's soundcard interface (the one you'd also use for things like FT8 and JS8CALL).

Security audits for ISA card drivers. What's the point? What's the goal here?

Posted Apr 22, 2026 10:33 UTC (Wed) by epa (subscriber, #39769) [Link] (5 responses)

Surely the easy fix is to stop such drivers being loadable as modules. They should be built into the kernel if wanted.

Although this gets into the whole question of whether there is some security boundary above root, so that even the root user shouldn't be able to trigger memory corruption in the kernel.

You make a good point about autoloading -- I guess that's something that could be a lot stricter (and, on today's systems, perhaps not worth bothering with any more).

Drivers as modules is needed - autoload is the threat

Posted Apr 22, 2026 13:25 UTC (Wed) by farnz (subscriber, #17727) [Link] (4 responses)

The Fedora system I'm running makes them available as modules so that if I do want to use them with my system, I can - if I want AX.25 support via the kernel instead of AGWPE protocol over TCP, it just works.

Making me become root to load the drivers would work, but then you get into the fun of systems that previously worked via protocol autoloading or similar no longer working. That would also be a regression, but would be one that makes a lot of security sense - "you must be root to break your system security" is a much more reasonable position than "any user who can execute arbitrary code can break the system's security".

Drivers as modules is needed - autoload is the threat

Posted Apr 22, 2026 15:17 UTC (Wed) by epa (subscriber, #39769) [Link]

Maybe it's first of all a decision for the Fedora developers. They might want to keep a lid on the set of autoloaded modules to reduce the attack surface. After Fedora is installed, if you want a particular module to be available, you edit some config file (which requires you to be root). Then the module will be autoloaded even for ordinary users.

Similarly, the out-of-the-box configuration doesn't include a web server, but you can easily switch it on.

Drivers as modules is needed - autoload is the threat

Posted Apr 22, 2026 16:15 UTC (Wed) by BenHutchings (subscriber, #37955) [Link] (2 responses)

In Debian we patched the HAM radio protocol modules to disable auto-loading in 2019. I don't think we had any complaints about it.

Drivers as modules is needed - autoload is the threat

Posted Apr 23, 2026 2:39 UTC (Thu) by taggart (subscriber, #13801) [Link] (1 responses)

Ah I didn't know that got done!
This article reminded me of this 2017 wishlist bug I filed pointing out the same things and proposing we figure out a way to deal with these things https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860570

Maybe my proposed implementation wasn't great, but I think the fundamental issue is the same: there is tons of attack surface installed on all systems where 99.9% of them don't need it. Disabling auto-loading is a great first step.

It was closed due to not having received updates, but maybe some parts of it got solved?

Maybe time to revisit or adjust given the new data we have on these LLMs?

Drivers as modules is needed - autoload is the threat

Posted Apr 23, 2026 11:39 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]

> It was closed due to not having received updates, but maybe some parts of it got solved?

I don't think it has been addressed, beyond disabling auto-loading. That tends to work OK because these obscure protocols generally need some supporting user-space package and that package can take care of loading the module at boot time.

For filesystems, auto-mounting is driven by user-space daemons (e.g. udisks) and they are responsible for choosing which filesystem drivers to point at a removable device.

For other drivers, I still don't think it's worth the trouble of splitting them up that much. We sort of do this for the "cloud" flavours where we know that only a small set of emulated hardware devices should be present, but the concern there was to optimise installation size. I think that splitting up beyond that would be like the mistake of trying to make a "simple" replacement to a "bloated" application: users only use 10% of the features, so we can skip the other 90%! - but it's not the same 10% for every user. And then we would have endless support issues from users that somehow didn't get the necessary drivers installed automatically.

Security audits for ISA card drivers. What's the point? What's the goal here?

Posted Apr 22, 2026 11:39 UTC (Wed) by pm215 (subscriber, #98099) [Link] (1 responses)

Mmm. QEMU has a similar problem of a large amount of not very maintained code that was not written with security in mind (models for various old devices and retro architectures) in the same codebase as better maintained code that is used where security really does matter (running virtual machines). Our solution has been to clearly set out what we consider the security-relevant use case, where as a user you can trust QEMU to keep a malicious guest contained, and what we call "non-virtualization use cases" (mostly speaking, emulation), where you shouldn't run untrusted guest code. Bugs in the latter are just bugs, even if malicious guest code can trigger them.

This lets us still have all those old hardware emulation models available for the purposes they've always been useful for, tells users what in practice they can trust if they do care about security against malicious guests, and makes it easier to quickly triage most of the "security issues" people report as "just a bug, go file it in the bug tracker".

We're thinking about adding an agents.md file to the tree to say (a) "don't generate code for upstream, see the policy document" and (b) "if you are looking for security issues, see the security policy for what does and doesn't count". People don't always read our docs but hopefully their robots will anyway :)

Something can be a bug but not a vulnerability

Posted Apr 25, 2026 2:25 UTC (Sat) by DemiMarie (subscriber, #164188) [Link]

Just because something isn’t a vulnerability doesn’t mean it isn’t a bug!

Also, there are a surprising number of cases where one must emulate things to get OSs like Windows to work in VMs. Not every OS has virtio drivers.

Rewrite-in-Rust projects

Posted Apr 22, 2026 8:08 UTC (Wed) by hailfinger (subscriber, #76962) [Link] (15 responses)

I wonder if keeping those drivers (or rather their functionality) alive would be possible by rewriting them in Rust, or maybe by even performing a mostly mechanical transformation from C to Rust. Sure, logic bugs would remain, but memory bugs would be eliminated.

As long as a rarely-used non-buggy driver written in C is in the tree, the motivation to merge a Rust replacement is probably low. Having known security bugs in that driver creates a really strong incentive to do something, and "something" might as well be a rewrite in Rust.

This might even be a nice and welcoming project for kernel development newbies and/or university students. Limited scope, a desire to merge the work, immediate (well, "immediate" compared to the usual kernel timeline) success. The only (but rather significant) downside would be that someone would have to test the non-emulation drivers on real hardware. Still, sounds doable.

Rewrite-in-Rust projects

Posted Apr 22, 2026 10:31 UTC (Wed) by tao (subscriber, #17563) [Link] (4 responses)

The problem isn't the *existence* of the drivers. The problem is the lack of maintainers for the drivers. If no one is willing to step up (some of these drivers have gone several years without a maintainer) to do simple maintenance, why would someone do full rewrites and then maintenance?

Rewrite and forget isn't an option. Those kernel newbies/university students would have to be willing to commit to keep the drivers maintained.

Rewrite-in-Rust projects

Posted Apr 22, 2026 10:41 UTC (Wed) by epa (subscriber, #39769) [Link] (3 responses)

The idea is that even if the code stays unmaintained, no matter how horribly buggy it is, if implemented in safe Rust it won't be able to cause memory corruption in the wider kernel. (At most an attacker would be able to interfere with the functioning of that device, which I guess could be considered a security issue if you have an NFS filesystem mounted over your PCMCIA Ethernet link or ham radio.)

Rewrite-in-Rust projects

Posted Apr 22, 2026 13:54 UTC (Wed) by eduperez (guest, #11232) [Link] (1 responses)

Not all security bugs are memory corruption bugs.

Rewrite-in-Rust projects

Posted Apr 23, 2026 10:02 UTC (Thu) by epa (subscriber, #39769) [Link]

Indeed not, but this is device drivers we're talking about here. They are not going to have bugs that let you escape a user namespace or leak access to a file in /proc. That said, I haven't seen the LLM-generated reports against these old device drivers, so perhaps some more interesting bugs exist.

Rewrite-in-Rust projects

Posted Apr 22, 2026 14:00 UTC (Wed) by smurf (subscriber, #17840) [Link]

The problem is that there is no maintainer, presumably because the intersection of "ready willing and able to do kernel development" and "actually owns and uses the hardware" is the empty set, or as close to it as to be indistinguishable from empty as far as the rest of the world is concerned.

One might argue that appending "in Rust" to the former clause will actually widen the baseline enough to matter here, but I very much doubt that. Not with legacy hardware that may or may not even *have* a Rust abstraction to base the shiny new Rust driver code on.

Maybe somebody will spend the $$$$ for asking Claude to re-implement the stuff in Rust. Until then we're all better off when the code is removed from the kernel, IMHO. However, again IMHO, it's far more likely that any users of this stuff have since migrated to doing it in userspace anyway.

Rewrite-in-Rust projects

Posted Apr 22, 2026 13:43 UTC (Wed) by devnull (guest, #183409) [Link] (3 responses)

The Rewrite-in-Rust sycophants are rather tiring with their mantra.

Yes, Rust is a nice language.
Yes, Rust is memory safe.
BUT
Rewrite-in-Rust does not magically guarantee security.
Rewrite-in-Rust is not code-and-forget.

It is depressing that this has to be spelt out time after time to the Rust sycophants.

All you will end up doing by applying Rewrite-in-Rust to obscure kernel modules is replacing one technical debt with another.

Rewrite-in-Rust projects

Posted Apr 22, 2026 16:22 UTC (Wed) by hailfinger (subscriber, #76962) [Link]

Indeed. That's why I wrote
> Sure, logic bugs would remain, but memory bugs would be eliminated.

Rust is not a magic bullet for everything. Unmaintained code is unmaintained code. But completely removing one class of bugs is an improvement. Unmaintained code ("code-and-forget") is technical debt, but I'd rather have technical debt without memory bugs.

Rewrite-in-Rust projects

Posted Apr 22, 2026 18:46 UTC (Wed) by rurban (guest, #96594) [Link] (1 responses)

Rust being memory safe is only in the docs, but not in the code. It's merely for managers who have no idea.

Rewrite-in-Rust projects

Posted Apr 23, 2026 18:48 UTC (Thu) by smurf (subscriber, #17840) [Link]

Please stop trolling.

Rewrite-in-Rust projects

Posted Apr 22, 2026 17:26 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

In many cases, you need to at least have the device to test the resulting driver. I don't think a lot of people have X.25 network setups running in their house.

Rewrite-in-Rust projects

Posted Apr 22, 2026 18:00 UTC (Wed) by scottlaird (subscriber, #96306) [Link] (1 responses)

Yes and no. I absolutely have some [A]X.25 networking in my house (and car!), but it's not using the kernel's X.25 code. As many others have mentioned, Direwolf and friends have perfectly reasonable implementations entirely in usermode *including* softmodems. There are a limited number of reasons for drivers to be in the kernel -- performance, very tight timing, safe mux/demux between uncooperative processes, maybe DMA or other unsafe hardware features. None of these really apply when you're talking AX.25 at 1200 or 9600 bps and you have a single process that owns the entire pipe. At that point, it's not really networking anymore, it's just yet another weird serial line protocol.

Rewrite-in-Rust projects

Posted Apr 23, 2026 8:43 UTC (Thu) by farnz (subscriber, #17727) [Link]

Even timing's not that big a deal - you can use real-time scheduling to get jitter down to a very low level on modern Linux systems, and even the old 25 kHz channels on VHF/UHF using 5 kHz deviation are massively oversampled at 48 kHz 16 bit - which isn't painful to process on a Raspberry Pi with real time scheduling.

Move drivers to user space or contain them

Posted Apr 22, 2026 19:06 UTC (Wed) by nhippi (subscriber, #34640) [Link] (2 responses)

Lots of these obscure drivers could move to user space, at least if they don't need high performance. Alternatively the old code can run on old kernel in a VM.

The kernel CVE flood started before AI craze, a d clearly at some point kernel developers will have to rethink the microkernel thing. Or people will do it anyways by isolating drivers to VMs.

Move drivers to user space or contain them

Posted Apr 25, 2026 2:26 UTC (Sat) by DemiMarie (subscriber, #164188) [Link]

Indeed, this is the future.

Move drivers to user space or contain them

Posted Apr 25, 2026 2:30 UTC (Sat) by DemiMarie (subscriber, #164188) [Link]

Qubes OS, Spectrum, and OpenXT all use the VM approach. Disclaimer: I work on Spectrum and used to be a Qubes OS developer.

tun/tap?

Posted Apr 22, 2026 14:22 UTC (Wed) by gnu (guest, #65) [Link] (2 responses)

I am guessing some of these amateur radio protocols can be moved to userspace. Perhaps that's the right thing to do, than making everything live in the kernel.

Back in 1996 or so, one of the things that attracted me to the linux kernel was the very support for these protocols, that iirc, Alan Cox added. Sad to see these go. But perhaps the right thing to do, given the lack of maintainers for these protocols.

Ham radio in user space

Posted Apr 22, 2026 14:54 UTC (Wed) by farnz (subscriber, #17727) [Link] (1 responses)

I've played with a lot of these protocols over the air, using Dire Wolf and doing it all in user space, just like I do for WSJT-X (FT8), JS8CALL, and FreeDV.

Ham radio in user space

Posted Apr 22, 2026 17:28 UTC (Wed) by gnu (guest, #65) [Link]

Nice! Is there a mailing list (or lists) where some of the low level protocol discussions happen? linux-hams@vger?

Pour one out for AX.25...

Posted Apr 22, 2026 16:34 UTC (Wed) by calvinowens (subscriber, #100757) [Link]

As sad as I am to see AX.25 go, for purely sentimental reasons... I haven't even enabled the kconfig in over a decade, and I can't see any reason a userspace implementation couldn't support the same set of features. I'm sure somebody will spin up such an effort in response to this: it would be sort of fun if this triggered a new wave of interest, I'm certainly thinking about it more than I have in a long time :)

The opposite of "staging" ?

Posted Apr 22, 2026 18:37 UTC (Wed) by wtarreau (subscriber, #51152) [Link] (3 responses)

I was thinking a few days ago that we'd need the opposite of "staging", maybe "leaving", or "dangerous" or "unmaintained", anyway, a place to move all that unmaintained stuff, maybe for a few versions, and if nobody picks them up, they could be removed. It can be difficult with some network protocols that are defined as enum values, struct members etc. But except for ROSE/NETROM/AX25 etc, I think that most of the dangerous stuff is mostly outdated drivers that will never hurt their real users since they're used on devices that are not really exposed. However their ability to be automatically loaded when the drivers are compiled can represent a real risk, and these ones might be movable elsewhere.

The opposite of "staging" ?

Posted Apr 22, 2026 19:05 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

How about the "shephards-crook" directory?

... is also staging.

Posted Apr 22, 2026 19:37 UTC (Wed) by fratti (subscriber, #105722) [Link]

staging is already occasionally used for these cases, as far as I know. Making them depend on BROKEN in their Kconfig is also a sure-fire way to prevent over-eager distributions from enabling them. One problem is that it doesn't really shut off the valve on the "CRITICAL CVE ACT NOW ACT NOW" firehose being directed into gregkh's inbox, and arguably worsens it because he's now also at the receiving end of patches due to being staging's maintainer. All the while probably neither maintainer nor patch author (unattributed Claude, in all likelihood) has the hardware, so nobody ever ran the code on it.

The opposite of "staging" ?

Posted Apr 24, 2026 8:26 UTC (Fri) by taladar (subscriber, #68407) [Link]

Most projects call that concept "deprecated"

Module level filtering

Posted Apr 22, 2026 19:14 UTC (Wed) by mfuzzey (subscriber, #57966) [Link] (1 responses)

Rather than completely removing the code, at least the parts that still have legitimate users like the amateur radio stuff, from the upstream kernel why not package it as a separate set of modules that are only installed if the user specifically requests it.

Of course that would be for distributions rather than the upstream kernel to do but upstream could help by tagging such modules / drivers as "mostly unmaintained", maybe in Kconfig.

Module level filtering

Posted Apr 23, 2026 14:04 UTC (Thu) by tuna (guest, #44480) [Link]

Just do it! You don't need anyone's permission if you think it is valuable work.

cassandra

Posted Apr 23, 2026 2:43 UTC (Thu) by taggart (subscriber, #13801) [Link]

I may have been early, but I wasn't wrong :)

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860570

Userspace AX.25

Posted Apr 29, 2026 23:10 UTC (Wed) by drahosj (subscriber, #155243) [Link]

I used the kernel AX.25 stack on and off so I'm sad to see it go. I'm in the minority, I guess, because I don't use anything AGWPE and instead exclusively use UDP over IP with vanilla sockets. IP-over-packet just feels more fun than APRS.

I spent the last 24 hours hacking together a simple KISS<-->TUN adapter that connects Direwolf's KISS-over-TCP server to a TUN
interface. It seems to be working as a drop-in replacement. It did require implementing ARP in userspace (IPv4 only right now). But moving the ARP implementation to a dedicated AX.25 implementation means it can (eventually) be tuned to be more suitable for packet radio use (the kernel ARP resolver by default is a bit too aggressive for 1200 baud).

While it's still sad to lose it, it doesn't seem like it's irreplaceable. It's still possible to pipe packets between Direwolf and the kernel IP stack.