Linus Torvalds says AI-powered bug hunters have made Linux security mailing list ‘almost entirely unmanageable’ Linux kernel boss Linus Torvalds has declared the project’s security mailing list has become “almost entirely unmanageable” due to multiple researchers using AI to find bugs and then filling the list with duplicate reports. Torvalds used his weekly state of the kernel post to deliver release candidate four for Linux 7.1 and …
Create a separate Linux kernel mailing list for issues found by AI, and make it very clear that anyone caught posting AI discovered issues on the main list will be banned and all their contributions to all Linux kernel mailing lists will be forwarded to /dev/null
They'll have a few volunteers/moderators willing to do the legwork to figure out which are new issues, and forwarding them to the main list.
Easier solution: the kernel team deploys these tools themselves, making everything they find automatically redundant when filed by outsiders, unless that outsider also brings the patch as Linus suggests.
Like it or not, the tools won't be going away. The only long-term solution is procedural change.
They won't, so it might as well be done in an orderly fashion.
The project doesn't need a bunch of duplicate reports and duplicate token spend by people trying to be helpful.
The project could make much better used of the money being wasted on duplicate bug reports. If people want to be helpful they should a donation.
Much depends on what you mean by “ keep anything AI away from the kernel.”
From what I’ve seen, definitely all code changes to the kernel need to have been fully scrutinised by a human, but the use of AI to find issues and to provide resolution assistance may be beneficial, which is effectively what Linus is saying.
Agreed. I don't use Artificial Ignorance to write or modify code, but I do ask questions and explanations of technology details I'm unsure of from the online tools available without giving them access to my code base.
If I like their approach/suggestion, I implement it, but within the constraints of my existing code base, which is itself maintained by a rule-based fractal model-to-code tool I've worked on for many years. I don't need AI to author code, I just need it to explain how to do things with modern frameworks and technologies that I didn't gain experience with during my working career (I'm retired and coding away 'cause I enjoy it!)
It also has the advantage of a 0-token fee. :)
The downvotes were because Linus isn't saying "Don't use AI"
He's saying, "It's OK to use AI to identify bugs, but if you do please don't just spam the list because others running the same tools will have found the same bugs. If you want to contribute, actually come up with a solution."
Not sure why you were downvoted. I don't like the idea of AI, but people are going to use it. And if it finds actual bugs, why is that a problem?
Maybe it is time for a procedural change, as you put it. With so many contributors perhaps it is time for a rethink.
The first problem with drive-by AI-generated problem reports is that the submitter did not check their report against the bug database before submitting it (I do not know, but I presume there is a kernel bug database!), and, if the AI-generated problem report is in the bug database, choosing to not submit that report.
The reasons I see for this drive-by-ism becoming more common are:
* Researchers, full professors, associate professors, and grad students see drive-by-ism as an easy way to look good to their clueless institutional and/or funding entities' management.
* The same groups of people panic, thinking that if they do not perform AI-generated bug report drive-bys, they will look bad compared to Dr. Scumbag Smith who submitted over 100 AI-generated bug reports in a single month. These reluctant drive-by-ers are acting out of self-defense.
* Some people are aiming to be paid bug bounties.
* Some people are aiming to receive praise for their 'efforts'.
* Some people are seeking plausible justification for their self-praise and belittlement of others, i.e., "i found a bug in ur kernel code haha you suxors you're phoolz i rule!!"
The second problem with, really, (so-called) AI-anything is the enormous amount of resources it consumes, which far-outweigh the benefits it brings. Nobody who knows any better uses an O(n^2) sorting algorithm. AI operations are humongously-more inefficient.
Simply
Us AI to review the mailbox and identify duplicate bugs submitted by AI
Ai identifies first unique submission and gives a sticker.
Then AI updates AI with "bug now known" answer
All duplicates get filed to /trash
Ai then congratulates AI on a job efficiently done
AI then fixes buggy code and releases update
The cycle begins again.
Linus sits back with a Long Island Ice Tea.
/s
They'll have a few volunteers/moderators willing to do the legwork to figure out which are new issues, and forwarding them to the main list.
Sounds like a job for an AI - go through the list of AI submissions collating and summarising those that identify the same issue, prioritising those that proffer a fix, then cross check each issue against the register of known issues and eliminate those from the AI list. Forward remaining issues to the human triage team for further assessment.
I don't see an inconsistency between what Linus and Greg have noted. The difference is that the people can read the submissions on the public lists and so the same chatbot doesn't keep submitting the same bug.
I agree the solution would be to make a separate but still private (write only) list for AI-discovered security bugs. But then have another chatbot read that list and make a summary of the commonly-reported bugs so people don't have to deal with the repetition.
That would leave the original security list for human-generated bug reports which tend to be unique even if people can't read the other reports.
No, Linus is correct
If it's a security bug found by generally available LLMs - that can be assumed to be public knowledge
Hence there's no need for a private list - it's presumed public, so public lists are fine
You could /maybe/ have a generic LLM bug report list, but there's not really much benefit - just ensure anyone submitting the bug report properly documents and checks it's a new report and it's all good
There is one exception - not generally accessible LLMs. New models that do different security analysis, etc., before they're public
But those are uncommon and run by people who can coordinate a unified set of reports that don't result in overlap - they can be handled like any other security specialist company
Yeah, that applies not only to the kernel. I have coworkers AI-ing a problem with a possible script solution which works in their test environment, and they truly want to be helpful. But the code looks a bit weird, strangely unoptimized and overly complex to the need. Sometimes, as a more recent example, a simple adjustment to the "Get-WinEvent" query speeds up things by more than a factor five, and a few other things reduce memory usage to less than a tenth. And things like a local object-cache hashtable reduces repeated AD-queries, which speeds up again a lot.. And suddenly the PS-script does not need 14 GB RAM until windows nukes the process, or is done with the job in less than ten minutes instead of several hours.
There are places where AI-ing can take off work, like UI stuff including interactive graphics for your data or script, and that code looks better than the above mentioned examples.
describe the bug."
Whether composed by an AI agent or a clueless human "AIhole" you could probably mechanically filter out the slop purely on syntactic grounds.
Or just /dev/null the list for six months during which the attention seekers will likely give up and bugger off to shit all over another poor sod's pride and joy.
Once again, Linus Torvalds swipes the clutter away and gets down to essentials.
"entirely pointless churn”
“AI detected bugs are pretty much by definition not secret.”
“AI tools [..] cause unnecessary pain and pointless make-believe work”
“If you actually want to add value, read the documentation, create a patch too, and add some real value on *top* of what the AI did.”
I would have thought that the Linux community would have been immune from AI-induced stupidity, but I was obviously wrong and AI has apparently enough charm to make even supposedly intelligent people fall for it. Humans will always be humans, I guess.
That said, between Torvalds and anyone else, where Linux is concerned I will always put Torvalds' opinion on the top of the list.
Also, he appears to be going a bit soft, with age. Where is the volcanic outrage ? I think it would be rather justified here.
A lot of people want a "quick fix" to their careers, and think that getting mentioned on the Linux kernel mailing list will do that.
So they burn a few rainforests worth of tokens finding and reporting something that's already been found and reported fifty times, and was resolved two months ago as "not a security issue" - which they'd know if they actually did the legwork.
Spoiler: Even if it is real and unique, an AI generated report won't help your career. A real patch might - but only if you wrote it.
" ... between Torvalds and anyone else, where Linux is concerned I will always put Torvalds' opinion on the top of the list."
Yes indeed.
My upvote and 99 more to that.
" ... appears to be going a bit soft, with age. Where is the volcanic outrage?"
No.
Just a bit older and having read the room, wiser.
Waiting for the next time where he will point to what he wrote and curtly ask: "You assholes can't read?"
It will be well deserved and unobjectionable.
.
> Also, he appears to be going a bit soft, with age. Where is the volcanic outrage ?
Linus' rants are mostly limited to people who do the same stupid thing over and over and ignore being told no.
His rants have gotten headlines often, but when you read past the headline, it's usually something like "on date, you were told this was wrong because of reason X. Then on date you tried again, and were again told that it was wrong because of reason X. Now you're trying a third time to do something that's wrong even though it's been explained multiple times? what's wrong with you?"
You generally need to have a track record that Linus himself is aware of - and imagine how many people he interacts with (occasionally it's a rant about how stupid the design from a certain company is - that's a different kettle of fish)
Has anyone estimated the likelihood of AI finding a (security) bug only because it is already known and reported, as opposed to the likelihood of finding a genuinely new problem? Constrained to a project, such as the kernel, with a well-defined public reporting/discussion mechanism?
Serious question. Counting known AI-generated duplicates vs. genuinely new AI-generated problems reported on the mailing list is probably a proxy for the lower limit, since presumably there are issues found by AI, checked by humans, classified as duplicates, and never reported.
False positives should also be added into the mix. As a matter of fact, duplicates are a kind of a false positive, if only genuinely new issues are regarded as true positives in the context.
Point is, the burden of checking should be on the people who use AI to hunt bugs/vulnerabilities. The tools may very well be useful, but the amount of checking effort per report-worthy issue would be nice to know before much effort is invested by many people.
Reading your piece suggests what is needed isn’t just another mailing list for AI discovered bugs,but something more akin to VirusTotal, where someone can upload their discovered bug and have it automatically assessed returning a known/unknown rating, with unknown bugs getting forwarded to humans …
Actually, in the special case of security bugs, that is exactly what we need.
The problem with security bugs is that they are deliberately kept as secret as possible until they are fixed. That is a necessary, and good, thing. But it means reporters have no idea whether they are reporting a duplicate or not.
While AI has many limitations, presumably it can be configured to keep things confidential. So an AI reviewing reports, collecting what it considers duplicates together, and telling the submitter that it believes that the report is a duplicate and is being worked on, would be valuable.
It's the Jevons paradox all over again.
This con was supposed to make the "work" more efficient. Getting to the solution more quickly, so you'd need less developers. The opposite is slowly becoming apparent. You have more work to do, because all these automated "tools" detect more issues/vulnerabilities (regardless of how practical they would be to exploit). There is becoming also a nere constant hum of cve's you have to patch (even when you don't use that libraries particular functionality). And the standard just getting things done 'work' consists of an endless stream of bloated AI gen MR pull requests, which look all right on the surface, and hey all the tests pass, and yeah sure I checked it out in dev/qa. And you merge it because the suits pile on the pressure to deliver, because hey you have AI now so you can do it in half the time with half the people. No one has time to actually think. But deep down there will be some subtle assumption the model has made on your behalf that is wrong. You won't spot it till prod is on fire and you'll spend all of the next few weeks sorting it out.
The junior devs have also completely outsourced their minds. Im getting buzzed constantly how should this work how should that work, IDKN jc draw a state diagram, decision tree or truth table and work it out like we used to. You can even use an llm to help with that. It's like this magic spell came along and everyone forgot the basics.
I'm telling you we're all fd. Any of these nitwits doing 300pull requests a day or whatever have basically just given up all hope on understanding what a system is doing. It's all just black box. Nothing is probably the test suit could be fudged by the bot. And you won't know. And this, all on financial and critical systems. You think the horizon scandal was bad or any of the other old school IT f ups. Just wait for what's coming.
/Rant over
This post has been deleted by its author
I don't see the “contrast” here:
“Torvalds' remarks contrast with recent comments from fellow kernel maintainer Greg Kroah-Hartman, who recently told The Register that AI has become an increasingly useful tool for the FOSS community”
One is talking about the mailing list and its users' behaviour, and the other about whether AI is useful (or not).
