Kernel code removals driven by LLM-created security reports
1–10 of 130 posts
Re: Kernel code removals driven by LLM-created security reports
#2They can't maintain the code so they are no longer going to maintain the code.
Re: Kernel code removals driven by LLM-created security reports
#3They can't maintain the code so they are no longer going to maintain the code.
Seems like this should have happened anyways and LLMs just finally forced them to admit it.
Re: Kernel code removals driven by LLM-created security reports
#4They can't maintain the code so they are no longer going to maintain the code.
It'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.
Re: Kernel code removals driven by LLM-created security reports
#5They can't maintain the code so they are no longer going to maintain the code.
> 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.
Re: Kernel code removals driven by LLM-created security reports
#6Most if not all of the listed stuff could be converted to used mode code.
Re: Kernel code removals driven by LLM-created security reports
#7Are 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?
Re: Kernel code removals driven by LLM-created security reports
#8Most if not all of the listed stuff could be converted to used mode code.
*user-mode code.
Re: Kernel code removals driven by LLM-created security reports
#9Are 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?
We are there. This is pretty much the reason why Mythos isn't being released publically.
Re: Kernel code removals driven by LLM-created security reports
#10Are 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?
> well-trained LLMs are more efficient in finding security holes than all but the best developers out there, even for OS kernel code?
No.
Like everything else an LLM touches, it is prone to slop and hallucinations.
You still need someone who knows what they are doing to review (and preferably manually validate) the findings.
What all this recent hype carefully glosses over is the volume of false-positives. I guarantee you it is > 0 and most likely a fairly large number.
And like most things LLM, the bigger the codebase the more likely the false-positives due to self-imposed context window constraints.
Its all very well these blog posts saying "LLM found this serious bug in Firefox", well yeah but that's only because the security analyst filtered out all the junk (and knew what to ask the LLM in the prompt in the first place).