GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel io_uring: task-work flag write can land on freed rings during a concurrent ring resize

CVSS 7.8CVE-2026-23275Kernel, userspace & hypervisorcurated

Impact

With DEFER_TASKRUN and SETUP_TASKRUN, task work added while the ring is being resized can OR IORING_SQ_TASKRUN into the old rings in the narrow window between the swap to the new rings and the old ones being freed - a write to freed kernel memory from an interface any unprivileged process can open. io_uring is on the hot path for the storage and network I/O that feeds GPU jobs (dataset loaders, object-store clients, high-throughput serving), so it is reachable from inside ordinary tenant containers unless it has been explicitly disabled. A local user on a shared GPU node is the realistic attacker, and the cost of the fix is a node reboot on a machine that is expensive to drain.

Who can reach it

Local unprivileged process that can call io_uring_setup with DEFER_TASKRUN and then resize its ring. No authentication beyond having a shell or code execution in a container where io_uring is permitted.

What to do

Apply the stable kernel update that adds the RCU-protected ->rings_rcu pointer; three stable branches carry the fix. Rollout is drain, install kernel, reboot each node. Where a reboot cannot be scheduled, blocking io_uring_setup for tenant workloads (seccomp profile, or kernel.io_uring_disabled) closes the path, but it will break any workload that depends on io_uring for I/O.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.