Greg K-H

Greg K-H's avatar
Greg K-H
🛡️ gregkh@social-kernel-org.mostr.pub
npub1hfel...k5ww
Looks like the AI companies have finally run out of money as they are asking various open source projects to test their closed source products for them for free. What could go wrong with giving access to an unknown tool to private code repos? If I didn't know better, I would think this is an elaborate phishing scam, or they have run out of data to scrape and need more training material. Gotta admire their brazenness... image
Prediction for the potential future: 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. "But copyright law will prevent this!" you say...
The kernel CNA assigned their 10000th CVE last week, CVE-2025-68750 So far the “stats” look like: Year Reserved Assigned Rejected A+R Returned Total 2019: 0 2 1 3 47 50 2020: 0 17 0 17 33 50 2021: 0 732 24 756 16 772 2022: 3 2041 47 2088 0 2091 2023: 1 1464 47 1511 0 1512 2024: 6 3069 96 3165 0 3171 2025: 73 2421 39 2460 0 2533 Total: 83 9746 254 10000 96 10179 Note, the “year” is the year the bug was fixed in the kernel tree, NOT the year the CVE was applied for/assigned.
Rust is is not a "silver bullet" that can solve all security problems, but it sure helps out a lot and will cut out huge swatches of Linux kernel vulnerabilities as it gets used more widely in our codebase. That being said, we just assigned our first CVE for some Rust code in the kernel:
Making sure you're not a bot!
 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.
Starting to write up a series of articles about the Linux kernel CVE work that has happened in the past 2 years, starting with some "back to basics" information about how Linux kernels are numbered as many people/companies really don't know how we do this, and it matters a lot in tracking bugfixes and how to determine "vulnerable" and "fixed" kernel releases:
Linux Kernel Monkey Log
Linux CVEs, more than you ever wanted to know
It’s been almost 2 full years since Linux became a CNA (Certificate Numbering Authority) which meant that we (i.e. the kernel.org community) ...
 and
Linux Kernel Monkey Log
Linux kernel version numbers
Despite having a stable release model and cadence since December 2003, Linux kernel version numbers seem to baffle and confuse those that run acros...
It has now been 0 days since a AI-hallucinated "security report" was sent to the kernel security team. Right now we seem to be averaging about 1 per week, not bad overall probably compared to other projects. To be fair, a real security bug was recently found with an "ai tool", but the authors of that at least took the time to verify it was real before sending it to us, and they provided a patch, so not all is doom and gloom.
Here is a hopefully-useful notice about Linux kernel security issues, as it seems like this knowledge isn't distributed very widely based on the number of emails I get on a weekly basis: - The kernel security team does not have any "early notice" announcement list for security fixes for anyone, as that would only make things more insecure for everyone. - The kernel community does not assign CVEs, nor do we deal with them at all. This is documented in the kernel's security policy, yet we still have a number of people asking for CVE numbers even after reading that policy. See my longer "CVEs are dead..." talk for full details about how the CVE process is broken for projects like Linux: https://kernel-recipes.org/en/2019/talks/cves-are-dead-long-live-the-cve/ - You HAVE to take all of the stable/LTS releases in order to have a secure and stable system. If you attempt to cherry-pick random patches you will NOT fix all of the known, and unknown, problems, but rather you will end up with a potentially more insecure system, and one that contains known bugs. Reliance on an "enterprise" distribution to provide this for your systems is up to you, discuss it with them as to how they achieve this result as this is what you are paying for. If you aren't paying for it, just use Debian, they know what they are doing and track the stable kernels and have a larger installed base than any other Linux distro. For embedded, use Yocto, they track the stable releases, or keep your own buildroot-based system up to date with the new releases. - Test all stable/LTS releases on your workload and hardware before putting the kernel into "production" as everyone runs a different % of the kernel source code from everyone else (servers run about 1.5mil lines of code, embedded runs about 3.5mil lines of code, your mileage will vary). If you can't test releases before moving them into production, you might want to solve that problem first. - A fix for a known bug is better than the potential of a fix causing a future problem as future problems, when found, will be fixed then. I think I need to give another talk about this issue to go into the above in more detail. So much for me giving a technical talk at Kernel Recipes this year...