How to handle people dismissing io_uring as insecure? (2024)

Stale reputations and “once bitten” attitudes

• Several comments compare io_uring’s reputation to PHP, Perl, Btrfs, MySQL, CoffeeScript, etc.: people freeze their opinion at an early, painful experience and ignore later improvements.
• This “scar tissue” leads many to avoid a technology entirely, even if it is now materially better.

Where the “io_uring is insecure” meme comes from

• The Wikipedia article is seen as a major source: it cites Google’s claim that ~60% of 2022 kernel exploits submitted to their bug bounty involved io_uring and notes it was disabled on Android, ChromeOS, and Google servers.
• A later Wikipedia addition asserting that io_uring is now “no less secure than anything else” is criticized as being poorly supported and self-citing this very discussion.
• Some point out Android’s history of shipping old kernels, implying many issues were already fixed upstream, but others note io_uring still has a steady stream of serious bugs and Google continues to find CVEs.

CVE counts and their meaning

• One comment lists io_uring CVEs per year, showing a rising count through 2024, with some high‑severity issues still in 2025.
• Others argue CVE volume is hard to interpret: it scales with adoption, kernel policy tends to assign CVEs liberally, and many entries are ordinary bugs or panics.
• There is disagreement on whether this history justifies labeling io_uring “insecure,” or simply “complex and still maturing.”

Security model gaps: filtering and containers

• A concrete security weakness today: io_uring “syscalls” cannot be filtered as precisely as classic syscalls via seccomp‑BPF/eBPF/LSMs, which weakens standard container hardening.
• You can block io_uring globally (disable its syscalls or compile it out), but that makes software depending on it harder to deploy in locked‑down environments.
• Security tool authors dislike that io_uring was designed with little initial consideration for filtering/auditing and later grew features like ioctl support, which are notoriously hard to sandbox.

Usage, threat models, and complexity

• Some would happily use io_uring on dedicated, performance‑critical systems (HPC, finance, specialized servers), but avoid it in multi‑tenant or highly locked‑down environments until filtering/auditing catches up.
• Others highlight non‑security concerns: the API is hard to use correctly; buffer and completion management can easily introduce subtle races and catastrophic failures under load.
• A counterpoint is that per‑thread rings and careful design can simplify things, and io_uring uniquely enables fully async patterns (e.g., async file open) that improve concurrency models.

How to respond to “io_uring is insecure”

• Several comments stress: don’t start from “critics are wrong.” Instead, acknowledge the real history of critical bugs and Google’s decision to disable it, then:
  • Present concrete data (CVE history, severity trends, comparison to other subsystems).
  • Be explicit about what io_uring does and does not change: it increases kernel attack surface; it doesn’t automatically make an individual application’s logic less secure.
  • Admit that trust must be rebuilt over time via a long period of quiet operation and better integration with security tooling.
• Practical strategies suggested:
  • Formal verification of the front‑end validation layer to address both real flaws and reputation.
  • Gaining vendor endorsements (RHEL enabling it by default, major clouds allowing it in managed runtimes).
  • Being honest about trade‑offs: if your software targets environments where seccomp‑based hardening is standard, you may need to avoid or gate io_uring.
• One meta‑point: it is acceptable to “agree to disagree”—for some threat models, disabling io_uring entirely remains a rational choice.