Kernel call interface "io_uring" - due to security issues, to disable it or, not?

Yes, yes, there was a CVE in 2022 which addressed a security issue with the Kernel call interface “io_uring” and, multiple Ring Buffers for asynchronous I/O ain’t new – I first came into contact with the things back in the mid 1980s with the DEC Standard Disk Interconnect serial interface …


But, there seems to be an ongoing question mark with regard to current security implications around the current Linux Kernel implementation.

Kernel documentation is here – <Documentation for /proc/sys/kernel/>

If I disable the thing then, because “io_uring_group” is set by openSUSE default to ‘-1’ only processes with the CAP_SYS_ADMIN capability may create io_uring instances.


Currently, here on Leap 15.6, there’s only the following capabilities set by default –

 # getcap /usr/bin/*
/usr/bin/cdrecord cap_ipc_lock,cap_sys_rawio,cap_sys_nice,cap_sys_resource=ep
/usr/bin/dumpcap cap_net_admin,cap_net_raw=ep
/usr/bin/kwin_wayland cap_sys_nice=ep
 # getcap /bin/*
 # getcap /usr/sbin/*
/usr/sbin/mtr cap_net_raw=ep
 #

Does anyone happen to know which system or KDE Plasma applications are using the “io_uring” Kernel call interface?

Qemu is using it e.g.

> ldd /usr/bin/qemu-kvm|grep liburing
        liburing.so.2 => /usr/lib64/liburing.so.2 (0x00007f80ade00000)
# zypper search --requires uring
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...

S  | Name            | Summary                                                        | Type
---+-----------------+----------------------------------------------------------------+-----------
   | libdex-1-1      | Shared library for libdex                                      | Paket
   | liburing-devel  | Development files for Linux-native io_uring I/O access library | Paket
   | liburing2-devel | Development files for Linux-native io_uring I/O access library | Paket
   | qemu            | Machine emulator and virtualizer                               | Quellpaket
   | qemu-img        | QEMU disk image utility                                        | Paket
   | qemu-pr-helper  | QEMU persistent reservation helper                             | Paket
   | samba           | A SMB/CIFS File, Print, and Authentication Server              | Paket
   | samba           | A SMB/CIFS File, Print, and Authentication Server              | Quellpaket

    Hinweis: Für eine erweiterte Suche inkl. nicht momentan aktivierter Remote-Ressourcen bitte
    'zypper search-packages' verwenden.

https://www.phoronix.com/news/Google-Restricting-IO_uring

# more /etc/sysctl.conf |grep -i uring
kernel.io_uring_disabled = 2

Yes, agreed, if you’re running a Samba server – in other words, almost each and almost every NAS box – you have a problem …


Where I’m becoming somewhat impatient is, the time being taken to add the CAP_SYS_ADMIN capability to those applications which could use the Kernel’s multiple Ring Buffers – including and especially network I/O …

  • The solution is there in the Kernel – it’s available – use it!!!

There is a Kernel document related to “FUSE over io_uring” – <FUSE-over-io-uring design documentation> – with a little note –

Fuse kernel requests are queued through the classical /dev/fuse read/write interface - until io-uring setup is complete.

One can therefore assume that, also for the Kernel, io_uring is currently on the “To-Do” list …

Instead of keeping io_uring just for Samba/QEMU enabled why not set io_uring_disabled to 1 and give Samba/QEMU rights using the io_uring_group or a similar method?

Given that, we haven’t really found anything other than –

  • libdex
  • GEOPM
  • Music Player Daemon
  • QEMU
  • samba

which requires io_uring, personally, I’ll set the value of “io_uring_disabled” to ‘1’ for a while – with the hope that FUSE still doesn’t use the thing …