Kernel code removals driven by LLM-created security reports

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...>

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

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

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

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

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?

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?

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

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.

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

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

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

[dead]

[dead]

[dead]

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.