GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel io_uring/waitid: canceled task work runs __do_wait() in the wrong task context

UnscoredCVE-2026-81010Kernel, userspace & hypervisorcurated

Impact

io_waitid_cb() ignored the tw.cancel flag, so when the fallback task_work path runs the callback from a kworker, __do_wait() performs its child lookup and retry against current - which is no longer the submitting task. The fix completes such requests with -ECANCELED and skips the siginfo copy, since canceled task work can run without the submitter's userspace context. Exposure is local to a task using io_uring waitid, reached on a teardown path rather than on demand; the record does not characterize an exploitable outcome beyond operating on the wrong task's state. On a shared GPU node the relevance is the same as the other io_uring issues: it is kernel state reachable from any tenant pod that can use io_uring.

Who can reach it

Local user or container task submitting io_uring waitid requests. No remote path and no authentication beyond code execution on the node.

What to do

Take the stable kernel update carrying the fix (two backport commits linked) and reboot the node. Blocking io_uring for untrusted workloads via seccomp or the sysctl removes the exposure in the meantime. No fixed mainline version is stated in the record beyond the commits.

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.