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: 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: and
My seat name tag for the EU CRA meeting today... image
Given the news of the potential disruption of the CVE main server, I've reserved 1000 or so ids for the kernel now, which should last us a few weeks.