6 ms·
Kernel code removals driven by LLM-created security reports
- staticassertion 6mo agoThey can't maintain the code so they are no longer going to maintain the code.
- sigmoid10 6mo agoSeems like this should have happened anyways and LLMs just finally forced them to admit it.
- bastawhiz 6mo agoYou're being downvoted but I think you're right in a lot of ways. If you read through the patches for some of the removals, the reasons come down to: - Nobody is familiar with the code - Almost all of the recent fixes are from static analysis - Nobody is even sure if anyone uses the code This feels a lot like CPython culling stdlib modules and making them pypi packages. The people who rely on those things have a little bit of extra work if they want a recent kernel version, and everyone else benefits (directly or indirectly) by way of there being less stuff that needs attention.
- fluidcruft 6mo agoIt's an interesting form of tree shaking. The overlap of bugs being found, nobody caring enough to bother read the reports or fix the code, and nobody caring that the modules are pushed out of main seems good.
- traceroute66 6mo ago> They can't maintain the code so they are no longer going to maintain the code. Yes, I don't see the point of maintaining technical debt just for the sake of it. The security environment in 2026 is such that legacy unmaintained code is a very real security risk for obscure zero-days to exploit to gain a foot in the door. Reading through the list I don't see it being an issue for the overwhelming majority of Linux users. Who, for example, still uses ISDN in 2026 ? Most telcos have stopped all new sales and existing ISDN circuits will be forcefully disconnected within 3–5 years as the telcos complete their FTTP build-outs and the copper network is subsequently decomissioned.
- devmor 6mo ago> Who, for example, still uses ISDN in 2026? Most TV and radio stations.
- traceroute66 6mo ago> Most TV and radio stations. I doubt it. And as I said, telcos have ceased new sales of ISDN and will be shutting down copper networks within 3–5 years. Therefore if there are still TV and radio stations still using it, they will be forced to stop using it by circumstance, i.e. they will find their ISDN will cease working after the telco shuts down the kit in the exchange.
- devmor 6mo agoYou can doubt it all you want, ISDN is used internally in broadcast all over the world. Telcos shutting it down has nothing to do with them and won’t affect them. Losing support in software however, does.
- traceroute66 6mo ago>You can doubt it all you want, ISDN is used internally in broadcast all over the world Since you claim to be a domain expert, give me hard named examples with independently verifiable links. At this stage I want facts, not anecdotes. Because right now, my semi-educated guess is they are all using IP-based streaming codecs and protocols for remote contributions, outside broadcast, studio links and pretty much everything else under the sun.
- mike_hearn 6mo agoNo, he's right. I have a friend who does voiceover work and is and announcer for the UK Channel 4. He does all his work from home using an ISDN link. It's a huge pita for him because the telcos don't want to know indeed, but it's the usual story with legacy workflows. I think it's also a fully switched system so you are guaranteed bandwidth with no packet drops or buffering which is clearly useful for broadcast work.
- goalieca 6mo agoMaybe attackers would focus on these unused bits for very niche products, but generally no one would waste their time. In general, drivers make up the largest attack surface in the kernel and many of them are just along for the ride rather than being actively maintained and reviewed by researchers.
- catlifeonmars 6mo agoWould you say the vast majority are back seat drivers?
- baq 6mo agoand the code is in the training set, so you can trivially[0] ask an LLM to summon it back either from memory or just by asking it to revert the removal commit. [0] not trivially if you want to validate if it works
- rasz 6mo agoMost if not all of the listed stuff could be converted to used mode code.
- dbdr 6mo ago*user-mode code.
- ferguess_k 6mo agoAre 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?
- olmo23 6mo agoWe are there. This is pretty much the reason why Mythos isn't being released publically.
- pocksuppet 6mo agoThe reason Mythos isn't being released publicly is to drive up Anthropic's valuation by making big promises.
- dymk 6mo agohttps://blog.mozilla.org/en/privacy-security/ai-security-zero-day-vulnerabilities/ https://blog.mozilla.org/en/privacy-security/ai-security-zer... > As part of our continued collaboration with Anthropic, we had the opportunity to apply an early version of Claude Mythos Preview to Firefox. This week’s release of Firefox 150 includes fixes for 271 vulnerabilities identified during this initial evaluation.
- warkdarrior 6mo agoSo you're saying Mozilla is in on it, hyping up Anthropic. Are they getting a kickback?
- bitwize 6mo agoWhat they're saying is that the capabilities of Mythos to find overlooked vulnerabilities in large code bases are real. We're in a new era for security. You're either using AI to catch vulnerabilities in your code... or someone else is, and 0wning you.
- 6mo ago
- jimmypk 6mo ago[flagged]
- cozzyd 6mo agoSeems 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
- doubled112 6mo agoRed Hat already removes a bunch of modules/drivers from the RHEL kernel that they don't consider enterprise. Xbox/PS controllers, for example. I believe some old RAID controller and WiFi drivers are removed too. Whatever they don't want to support.
- rwmj 6mo ago(Working for Red Hat) We actually opt devices in to our kernel. A couple of years ago an overzealous kernel maintainer removed the watchdog drivers used by qemu from the kernel and it took me ages to get those added back in.
- mmsc 6mo agoUnmaintained code is a security issue in of itself, so this is of course a net benefit.
- xbar 6mo agoThis can be accurately generalized: code is a security issue in and of itself.
- catlifeonmars 6mo agoThis can be generalized: in and of itself.
- mey 6mo agoNow if only I could get the product team to fully understand that implication.
- brookst 6mo agoThat’s reductionism, not generalization. Generalizations that lose accuracy are not valid. “Ice cream is sweet, and candy is sweet, so food is sweet” is reductive.
- bozdemir 6mo ago[dead]
- KJs6ZxELzQM37O 6mo agoA 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
- deleted 6mo ago[deleted]
- cyanydeez 6mo agoYou're arguing to pay your taxes instead of spending money on buying politicians.
- NooneAtAll3 6mo agocan 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?
- gslepak 6mo ago> why do they even need to be in kernel People have been asking this question since Linux was first invented…
- s20n 6mo agoI could never in a million years have imagined that LLM-slop driven fuzzing would become the ultimate vindication for the microkernel philosophy
- drewg123 6mo agoLinux is actively hostile to out-of-tree drivers. There is no stable driver API, and interfaces change at the drop of a hat. Maintaining an out of tree driver is a constant nightmare where you're always dealing with interfaces changing out from under you. I wrote and maintained 10GbE drivers for a small company in the 2000s, and just the SHIM file for our driver on Linux to massage over API differences was well over 1000 lines. I think it was close to the same size as the entire driver for one of the BSDs.
- terryot 6mo agoA counterpoint: I recently asked Claude to port an obsolete ~2010 driver to latest kernel by asking Claude to "make it work". Few builds later and few crashes later, I had a working driver, with DMA, modern Io map protection, etc. It's not a nightmare anymore to port drivers
- achierius 6mo agoGP meant moving the driver into userspace, which is much less painful due to the stable userspace APIs.
- s20n 6mo agoWhile 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.org/ https://lwn.net/ml/all/20260421021824.1293976-1-kuba@kernel....> [2] : <https://lore.kernel.org/linux-hams/CAEoi9W5su6bssb9hELQkfAs7-xicCrrS7A4_Oo9K8but-jav5g@mail.gmail.com/T/#mbbb99383305e32a2edd357403b601d96283d7ecb https://lore.kernel.org/linux-hams/CAEoi9W5su6bssb9hELQkfAs7...>
- ajross 6mo ago> more modern protocols (in userspace) That's really it. The list of things that "need" to be in the kernel is shrinking steadily, and the downsides of having C code running in elevated privilege levels are increasing. None of that is about LLMs at all, except to the extent that it's a notable inflection point in a decades-scale curve. The future, and we basically all agree, puts complexities like protocol handling and state in daemons and leaves only the hardware, process and I/O management in the kernel. Basically, Tannenbaum was right about the design but wrong about the schedule and path to get there.
- anthk 6mo agoExcept it's several times slower doing TCP/IP in userspace with programs than having a proper kernel for it, that's it, Hurd.
- rwmj 6mo agoI don't think this is actually true (eg. DPDK), but even if it is, you can put the driver in userspace (tun/tap + vfio/libusb/ioport/...) and still use TCP/IP in the kernel.
- 6mo ago
- tristor 6mo agoRealistically, 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.
- Krutonium 6mo agoI actually use a capture card on PCI but I'm well aware I'm unusual.
- badsectoracula 6mo ago> They should be separated kernel modules in their own tree. The main issue with this is that by being on a separate tree they do not benefit from the API breakage updates in the kernel. After all the main benefit that kernel devs mentioned over the years for keeping drivers in the kernel instead of separate trees is that the code gets updated whenever internal APIs change.
- sscaryterry 6mo agoHere's the thing, all of these problems are pre-existing. All LLMs are doing is shining a big bright light on it.
- socratic_weeb 6mo agoWe are talking about drivers for devices from the last century which nobody even uses anymore. This isn't "shining light" on important pre-existing issues that have been ignored for too long or something, it isn't helping. The only problem here, if any, is the false sense of confidence given by LLMs to people who have no business touching kernel code.
- tssva 6mo agoIf they are drivers for devices from the last century which nobody even uses anymore why keep them in the kernel when they, as shown by LLMs, are potential sources of security vulnerabilities? Seems more logical to take the action being taken and remove them.
- skydhash 6mo agoI like OpenBSD for that. If there's something that no one uses and wants to maintain, it's removed. That happened with the bluetooth driver. It was too complicated and no one missed it enough to add it back.
- brookst 6mo agoYou don’t see any issue with insecure drivers for obsolete hardware, exactly the kind of thing that is most prevalent in an industrial control type applications? Stuxnet should have been a wakeup call to everyone: the boring, obsolete, “safe because nobody browses TikTok on it” hardware is exactly the highest risk.
- cestith 6mo agoIf you only need 100 Mbps the 3Com 3c905 series of PCI Ethernet cards are still some of the most reliable hardware you can put into your industrial PC that still has PCI slots. ISDN and ax25 are still really useful if you have low-bandwidth but low-latency needs like sensor data. Now those are niche use cases, but they do exist. However, what’s wrong with removing insecure code for these niche cases? Either someone will step up to actually maintain it, or newer versions of the kernel will be leaner and have less historical cruft.
- deleted 6mo ago[deleted]
- Create 6mo agoWhen LLM reports the bug, is should be used to fix it on the same occasion. Nobody will bother afterwards.
- skeledrew 6mo agoLLM being able to find bug doesn't necessarily equate to LLM being able to satisfactorily fix bug. Be happy that the bugs are being uncovered in the first place and brought to the attention of those who are concerned with their resolution.
- the_biot 6mo agoThat's literally advocating for filling the kernel with AI slop. Not that it's not going to happen; Linus is already a vibe-coder, and several maintainers have fallen for the LLM crap as well.
- gpm 6mo agoPerforming the charity work of discovering bugs before someone evil uses them to cause damage does not somehow obligate you to perform more charity and fix those bugs.
- anthk 6mo agoDamn 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 6mo agoNo meshnet for the people, because of surv^U security.
- canarias_mate 6mo ago[flagged]
- segmondy 6mo agoSeems 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 6mo agoThere really shouldn't, people don't have to include things in their kernel builds they don't need.
- notepad0x90 6mo agoI 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.
- adnasalk 6mo ago[flagged]
- beyondscaletech 5mo ago[dead]