Comment by yorwba
7 months ago
> you could look at https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=io_uring
CVE count by year:
2019: 1
2020: 1
2021: 10
2022: 15
2023: 19
2024: 21
2025: 10
7 months ago
> you could look at https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=io_uring
CVE count by year:
2019: 1
2020: 1
2021: 10
2022: 15
2023: 19
2024: 21
2025: 10
I expect CVEs to be directly proportional to project usage and popularity, and inversely proportional to maturity, which makes things a lot more complicated.
And also directly proportional to the publicity of the CVE system. If you're creative enough in your writing, any bug in any program can be filed as a CVE, and filing CVEs is much more interesting carreer wise than filing bug reports.
Any decently sized project has probably seen an increase in reported CVEs over the past 5 years, simply because the number of CVEs total has grown.
I'd also expect average CVSS severities to go down over time. While they definitely did get significantly lower in 2024, there's still some high severity stuff in 2025.
Looking through these CVEs, very few of the recent entries seem to be actual security bugs. Most are run-of-the-mill bugs as far as I can tell.
If a kernel panic is considered a security issue, anyone using Nvidia's drivers should fear for their lives.
> If a kernel panic is considered a security issue
It's normal to consider a non-root userspace program causing a kernel panic a security issue
That very much depends on your security posture. For a desktop computer, with a single user, panicking the kernel is at most a mild inconvenience. As it's said, it's a denial of service, but the service being denied is your own service.
5 replies →
This has to do with their policy on assigning CVE numbers, which is that pretty much any bugfix might be security-related because it’s the kernel, so it doesn’t take much to get a number assigned. See https://docs.kernel.org/process/cve.html.
I seem to recall that Linus Torvalds has the opinion that he doesn’t much treat security bugs more differently than he does regular kernel bugs. Perhaps this is why?
1 reply →
It seems a little dubious to brand something "insecure" based on the number of fixed bugs.
Is io_uring a complex and therefore bug-prone API surface? perhaps.
The `curl` project has a similar number of CVEs listed if you search for it, but we generally don't characterise curl as insecure.
If you're not using io_uring then it could make sense to disable it as a hardening measure, but I don't think the existence of now-fixed CVEs is a reason not to use it.