3 ms·

> How to handle people dismissing io_uring as insecure? It is, in the general case, hard to prove something secure (because it's hard to prove a negative). It

> How to handle people dismissing io_uring as insecure? It is, in the general case, hard to prove something secure (because it's hard to prove a negative). It might help to show CVEs per month/year/whatever related to it vs anything else, preferably with a clear downward trend. For example, you could look at https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=io_uring https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=io_uring ... although I struggle to read that as supporting the case you want to make. > I have had to deal with handful of these people from different sectors as well. Since I am actively working on project based on io_uring, I have had people saying all kinds of hmm... "crap", its so baseless! Can't even talk to them with actual facts. So what are those facts? Because all this thread has is people handwaving that it used to have a worse design, and everything has bugs and this isn't different, and implying that it's better. If it's better, show that.

yorwba 1y ago
> you could look at https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=io_uring 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
- franciscop 1y ago
  I expect CVEs to be directly proportional to project usage and popularity, and inversely proportional to maturity, which makes things a lot more complicated.
  - delusional 1y ago
    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.
  - sigmoid10 1y ago
    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.
- jeroenhd 1y ago
  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.
  - gkbrk 1y ago
    > 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
    - delusional 1y ago
      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.
      - mjg59 1y ago
        It's normal to consider it a security issue. Whether you consider it your security issue is contextual.
      - Rygian 1y ago
        Security, as the reunion of Confidentiality, Integrity, and Availability (CIA), definitely includes vulnerabilities where a malicious user can trigger a kernel panic, as it impacts Availability directly, and potentially Integrity as well in an indirect way. The distinction you make is a separate step down the line: you do a risk assessment and decide that, in your particular context, a specific vulnerability is not a threat worth defending against. For that same vulnerability, others will reach different conclusions in their respective risk assessments. That doesn't make it any less of a vulnerability.
      - tsimionescu 1y ago
        If you can install a program that runs at system startup and panics the kernel, that's beyond mild inconvenience - it's potentially a major IT scramble for a whole company's fleet, for example. Even for a server machine, it might require complicated debug procedures and/or physical access, since you can no longer just SSH into the system.
- Retr0id 1y ago
  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.
dmvdoug 1y ago
CVE statistics are also pretty hard to interpret in light of the kernel team’s willingness to assign CVE numbers for most any bugfixes.

yorwba 1y ago

> you could look at https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=io_uring 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

franciscop 1y ago
I expect CVEs to be directly proportional to project usage and popularity, and inversely proportional to maturity, which makes things a lot more complicated.
- delusional 1y ago
  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.
- sigmoid10 1y ago
  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.
jeroenhd 1y ago
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.
- gkbrk 1y ago
  > 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
  - delusional 1y ago
    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.
    - mjg59 1y ago
      It's normal to consider it a security issue. Whether you consider it your security issue is contextual.
    - Rygian 1y ago
      Security, as the reunion of Confidentiality, Integrity, and Availability (CIA), definitely includes vulnerabilities where a malicious user can trigger a kernel panic, as it impacts Availability directly, and potentially Integrity as well in an indirect way. The distinction you make is a separate step down the line: you do a risk assessment and decide that, in your particular context, a specific vulnerability is not a threat worth defending against. For that same vulnerability, others will reach different conclusions in their respective risk assessments. That doesn't make it any less of a vulnerability.
    - tsimionescu 1y ago
      If you can install a program that runs at system startup and panics the kernel, that's beyond mild inconvenience - it's potentially a major IT scramble for a whole company's fleet, for example. Even for a server machine, it might require complicated debug procedures and/or physical access, since you can no longer just SSH into the system.
Retr0id 1y ago
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.

dmvdoug 1y ago

CVE statistics are also pretty hard to interpret in light of the kernel team’s willingness to assign CVE numbers for most any bugfixes.