CVE-2026-81010

The Linux kernel's io_uring waitid implementation fails to honor the tw.cancel flag in its completion callback io_waitid_cb(), so when task work is diverted to the fallback kworker path (because task_work_add() can no longer queue to the submitting task), the callback still enters __do_wait(). Because waitid is inherently task-context dependent — __do_wait() looks up children relative to 'current' and the retry path uses current->signal->wait_chldexit — running it from a kworker makes the wait operate on the wrong task entirely, potentially touching kernel state without the submitting task's userspace context and leading to memory corruption or wrong-context siginfo handling. A local attacker with low privileges who can issue io_uring waitid requests on an affected kernel could trigger this; the issue is rated High (CVSS 7.8, AV:L/PR:L) with high confidentiality, integrity, and availability impact, consistent with local privilege escalation. Any system running a kernel that includes io_uring waitid support is affected, though exploitation requires local code execution and use of the io_uring waitid operation. No public proof of concept is known and the flaw is not in CISA's KEV, so exploitation is currently none known.

What to do: Patch to a kernel containing the fix (io_waitid_cb() now honors tw.cancel, completes with -ECANCELED, and skips the siginfo copy) as soon as your distribution backports it. On hosts where io_uring is not needed, consider disabling it via the kernel.io_disabled sysctl on kernels that support it or seccomp/LSM rules blocking io_uring setup. Watch for kernel oops reports or anomalous child-reaping behavior from processes using io_uring waitid.