Kernel code removals driven by LLM-created security reports

[Posted April 22, 2026 by corbet] 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] (2 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] (1 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] 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.

I prefer bogus Amateur Radio than no driver Posted Apr 22, 2026 7:12 UTC (Wed) by Alterego (guest, #55989) [Link] (3 responses)

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]

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] (6 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] (5 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] (4 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)

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]

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] (4 responses)

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] (2 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] (1 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]

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]

Rewrite-in-Rust projects Posted Apr 22, 2026 8:08 UTC (Wed) by hailfinger (subscriber, #76962) [Link] (2 responses)

Rewrite-in-Rust projects Posted Apr 22, 2026 10:31 UTC (Wed) by tao (subscriber, #17563) [Link] (1 responses)

Rewrite-in-Rust projects Posted Apr 22, 2026 10:41 UTC (Wed) by epa (subscriber, #39769) [Link] 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.)