@wdormann@joshbressers@Viss I love it how people think that "coordination of vulnerabilities" is actually something that can be done these days. Think of just who uses the software in question, and who should, and should not, be on such a list to get a "early disclosure notification".
As I have said for quite some time now, all early-disclosure lists are leaks, otherwise why would your government allow them to be in existence?
Software, and specifically open source software, runs the world. So should the whole world be on that notification list? :)
Curiosity got the best of me, and I clicked on the links and this just looks like an OpenAI "sales funnel", which is pretty hilarious when you consider the target was open source security teams, none of which could ever fill out these types of forms without flat out lying.
When the AI coding agent companies are just about to run out of money, down to their last few % raised as none of their customers are actually paying the real cost required to run these services, they pivot and take all of the uploaded code that was willingly sent to them, turn it into thousands of products / services to sell / rent, disconnect the public api endpoints leaving their old customers helpless as they no longer remember how to program "in the raw" and can not understand their own codebases, and compete directly against them putting their own customers all out of business which finally results in a positive income stream and "validation" of the coding agent companies previously over-hyped business valuations.
That being said, we just assigned our first CVE for some Rust code in the kernel: https://lore.kernel.org/all/2025121614-CVE-2025-68260-558d@gregkh/ where the offending issue just causes a crash, not the ability to take advantage of the memory corruption, a much better thing overall.
Note the other 159 kernel CVEs issued today for fixes in the C portion of the codebase, so as always, everyone should be upgrading to newer kernels to remain secure overall.
And if you are stuck with that kernel version for some reason, go ask your vendor to fix those 1500+ CVEs, otherwise you are paying for support that doesn't actually do anything for you...
@ncopa You do NOT want to see the kcbench results for the riscv system I have here, it's so sad it's not even funny. So sad I haven't even powered it on in a few months, it's pretty much useless :(
@msw@jacques@bagder I have no problem adding additional data like "This config option means you will not be vulnerable" to our records today, if people want to submit that information to us. We take patches and additions to the kernel cve.org records on a weekly basis from vendors that work to narrow down affected kernel ranges and add additional references.
So we could do what you want today, no changes to anything that cve.org does right now would be needed, just send us a patch! But that was not what was being proposed at all, unfortunately.
@stsquad@hrw Fixing the lack of almost all riscv soc drivers to be upstream so that I can boot a kernel.org release on one of them (i.e. a normal developer can test their changes) would be a good start. Which is one of the things that article says...
"How could you claim to have a neutral, informed opinion on LLMs without signing up for a bunch of subscriptions and constantly talking to the liar machine to see if it told a truth today?"
I'm seeing multiple of these type of "reports" per week now for Linux. Why do people think that an LLM can somehow do better than a compiler and also not even test their proposed changes to verify they even do anything?
And yes, the tool is obviously broken, I looked at the first 3 "issues" found and just laughed, thinking this was a joke, but it seemed to actually be real, which is sad on so many levels...