Kernel code removals driven by LLM-created security reports

staticassertion

They can't maintain the code so they are no longer going to maintain the code.

rasz

Most if not all of the listed stuff could be converted to used mode code.

ferguess_k

Are we already in the time, or close to the time, that well-trained LLMs are more efficient in finding security holes than all but the best developers out there, even for OS kernel code? Can someone educate me on this?

cozzyd

Seems like there should be some "level of maintenance" metric for modules and distros can pick which they include by default and which are packaged separately based on what they care about. Arch users will build the world but an EL user who needs an unmaintained module would have to explicitly install kmod-isdn or even build it themselves

mmsc

Unmaintained code is a security issue in of itself, so this is of course a net benefit.

KJs6ZxELzQM37O

A lot of money seems to be placed to find bugs in open source projects right now... maybe they can spend just a little bit of this money on people to fix these bugs

NooneAtAll3

can such drivers be moved out of kernel? what exactly stops that? why do they even need to be in kernel repo and not brought at/after install time?

s20n

While I know that it may have been a security liability, I'm particularly sad that they're removing the AX.25 module from the kernel. > 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. This thread from the linux-hams mailing list [2] has more insight into this decision. I guess the silver lining is that, more modern protocols (in userspace), written in modern languages will become the norm for HAM radio on linux now. [1] : < https://lwn.net/ml/all/20260421021824.1293976-1-kuba@kernel.... > [2] : < https://lore.kernel.org/linux-hams/CAEoi9W5su6bssb9hELQkfAs7... >

tristor

Realistically, that list of components are mostly things that have not been used in modern computing devices for over a decade. Nothing prevents someone from providing a module from out of the kernel tree to ship these drivers or delivering some of these capabilities in user space, and if they are unused and unmaintained I would rather they're not shipped in the kernel. Be real with yourself, do you know anyone using ISA or PCI in 2026? Everything is built on PCI-E except in specific industrial settings or on ancient hardware that's only relevant for retrocomputing. Is anyone using the ATM network protocol anymore? MPLS and MetroE mostly replaced ATM, and now MPLS is being largely supplanted by SDWAN technologies and normal Internet connections. I have been doing networking nearly my entire career in some capacity, the last time I touched X.25 or Frame Relay was in the early 2000s, the last time I touched ATM was in the mid early 2000s... the last time I touched ISDN was in the mid 2010s, and that was an IDSL setup, which is itself a dead technology. The last laptop I owned that had a PCMCIA card slot was manufactured in 2008. I don't want to see these capabilities completely disappear, but there's no reason they should ship in the mainline kernel in 2026. They should be separated kernel modules in their own tree.

sscaryterry

Here's the thing, all of these problems are pre-existing. All LLMs are doing is shining a big bright light on it.

Create

When LLM reports the bug, is should be used to fix it on the same occasion. Nobody will bother afterwards.

anthk

Damn it, HAM was always an asset and NOT just hamradio related, but other protocols such as some mesh network. Can't wait to AI braindead folks get collapsed down for the good.

anthk

No meshnet for the people, because of surv^U security.

segmondy

Seems there should be a "hobbyist kernel" with all that kernel code, you run at your own risk but get all the toys for your obscure use cases.

notepad0x90

I think "won't fix" should be normalized, even for critical security bugs. Software exists to be used, not to be secure. These are not useless pieces of code. If they were useless, then no one is using them, so there is no security risk. This is equivalent to turning off (or destroying) a computer to secure it. Alternatively (and I'm disappointed Linux/Greg K.H. haven't done this), drivers and other isolated modular code should be marked as unmaintained, and for those with reported vulnerabilities, a similar config flag set. Require explicit acknowledgement by kernel builders to include them in the build config. Things have been trending badly with Linux in this area, it feels like it's lost it's original calling, and is now heavily influenced by PR and corporate interests. The desktop Linus used in the 90's to write Linux should be able to run the current Linux kernel. But it doesn't even support the CPU architecture any more! Some of us have perfectly good old hardware we can put to modern (non-networked) use, but we have to either use netbsd (if it supports the task/program), or generate more e-waste and dump the hardware in the bin. And buy yet another RPI, and waste money and resources. But at least, so long as it is simple use cases that don't require modern software, you can just slap an old version of Linux on it, but at least in my experience, stability was more of an issue for older drivers than it is today, so Windows 98 or XP is a better choice sometimes for x86.