Doesn't the Linux kernel encourage reporting on the public mailing list for kernel vulnerabilities that were found using AI? If I remember correctly they introduced that policy after the security mailing list got swamped with multiple reports for the same vulnerabilities
I don't think AI is of much concern, if you actually have a valid security issue.
No-one, really will care if you discovered it via AI or otherwise. Because, the weight of the bug itself should outweight other concerns. This is how professional security works. There will always be one concern or the other about a bug but what carries more weight will determine the direction that the disclosure process takes.
A valid security bug, by itself should carry enough technical weight that concerns about whether it was discovered through AI or otherwise should become irrelevant.
Anyways, it mostly seems like people don't really care much about computer security at Linux. I would like to think they care more about infrastructure and related security issues because, well, if my computer is an open book, then why would security issues around it be a concern?
As it should. If an LLM discovered them you should assume that another LLM, or another person running the same LLM, could find them. They are effectively public already.
No. I have an LLM and didn't discover it. Folks in HR have LLMs but can't produce the same software you can. Just because an LLM could discover it does not mean that it has been discovered yet. Responsible disclosure is still a valuable thing.
Still bleary eyed, but: Most severe ones are in SMB and KSMBD, which apparently have implementations in kernel space. I think this doesn't impact anyone not using KMB.
Others are LPEs, but two have been deleted by now, so can't be sure of the details.
TrendMicro's site opens up with a big big "Advancing AI-Native Security with Anthropic". Which checks out I guess.
Doesn't the Linux kernel encourage reporting on the public mailing list for kernel vulnerabilities that were found using AI? If I remember correctly they introduced that policy after the security mailing list got swamped with multiple reports for the same vulnerabilities
On first glance it seems you are right.
> If you resorted to AI assistance to identify a bug, you must treat it as public. https://github.com/torvalds/linux/blob/master/Documentation/...
I don't think AI is of much concern, if you actually have a valid security issue.
No-one, really will care if you discovered it via AI or otherwise. Because, the weight of the bug itself should outweight other concerns. This is how professional security works. There will always be one concern or the other about a bug but what carries more weight will determine the direction that the disclosure process takes.
A valid security bug, by itself should carry enough technical weight that concerns about whether it was discovered through AI or otherwise should become irrelevant.
Anyways, it mostly seems like people don't really care much about computer security at Linux. I would like to think they care more about infrastructure and related security issues because, well, if my computer is an open book, then why would security issues around it be a concern?
Anyways...
Enough said here - lol
1 reply →
As it should. If an LLM discovered them you should assume that another LLM, or another person running the same LLM, could find them. They are effectively public already.
No. I have an LLM and didn't discover it. Folks in HR have LLMs but can't produce the same software you can. Just because an LLM could discover it does not mean that it has been discovered yet. Responsible disclosure is still a valuable thing.
The headline should include Trend Micro's name for shaming purposes. Amatuerish.
Still bleary eyed, but: Most severe ones are in SMB and KSMBD, which apparently have implementations in kernel space. I think this doesn't impact anyone not using KMB.
Others are LPEs, but two have been deleted by now, so can't be sure of the details.
TrendMicro's site opens up with a big big "Advancing AI-Native Security with Anthropic". Which checks out I guess.
I'm not surprised because the disclosure process of https://hackerone.com is completely and openly public.
But they have also disabled Linux as one of the products that they work with.
What an entertaining season in the simulation
Is this a parody article?
This is like saying "Linux source code leaked"
It's being a great season, techsecurity-wise.
On HN everyone is a security engineer.
There are only two types of people: Those who are security engineers, and those who pretend to be.
They wanted "full stack", so they found hires with 1/10th of an education in each of 10 different fields.
The boss class are rich because they're smart. /s
2 replies →
Can we kick SMB implementations out of the kernel please? If not, can we please get PHP mainlined in the kernel?
SMB was "imported" into the kernel as an optimization for the user-space version - heh
Finally the last vulnerabilities of the year.
> Finally the last vulnerabilities of the year ... until today
Fixed that for you
"accidentally"
I feel paranoid enough now to blame ai companies to try to induce panic and proclaim "buy our product to save yourself"
To be honest and fair, in this situation I don't believe this is something accidental.
It probably just happens that the security concerns at ZDI don't match the security concerns at Linux(the vendor).
So, it turns out that this vendor is difficult to work with ....
I mean - heh
Agree, wild stretch to accidentally send this loot to a mailing list.
are those posted by AI?
[dead]