From mboxrd@z Thu Jan 1 00:00:00 1970 From: AL-KERNEL To: kernel-cve@kernelcve.org Subject: [CVE-2026-81010][MODERATE REGULAR] io_uring/waitid: honor task_work cancellation Date: Fri, 11 Sep 2026 19:26:48 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-AL-KERNEL-CVE: CVE-2026-81010 X-AL-KERNEL-Priority: MODERATE REGULAR X-AL-KERNEL-Severity: MODERATE REGULAR X-AL-KERNEL-Base-Severity: MODERATE X-AL-KERNEL-KPANIC: NO X-AL-KERNEL-ActionableScore: 4 X-AL-KERNEL-ActionableScore-Lower: 3 X-AL-KERNEL-Commit: 7bc98e2de8c58a2bfaf0f540eb096a386ecfc96c List-Id: CVE: CVE-2026-81010 Priority: MODERATE REGULAR AL-KERNEL base severity: MODERATE KPANIC flag: NO Patch: io_uring/waitid: honor task_work cancellation Commit: 7bc98e2de8c58a2bfaf0f540eb096a386ecfc96c Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7bc98e2de8c58a2bfaf0f540eb096a386ecfc96c Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-81010 Analysis date: Fri, 11 Sep 2026 19:26:48 -0400 ActionableScore: 4 ActionableScore lower bound: 3 Actionable bucket: Borderline / manual review recommended Manual review required: YES Summary: No one-sentence report phrase was found. ====================================================================== ABOUT THIS REPORT ====================================================================== The original Linux kernel CVE announcement for CVE-2026-81010 is available here: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-81010 The original announcement does not normally provide a security severity estimate, CVSS assessment, or enough information to determine whether the reported kernel bug represents a practically relevant security issue. This report was generated by AL-KERNEL, an AI-assisted Linux kernel vulnerability analysis system developed by Alexander Larkin. It combines an autonomous classifier with LLM-assisted technical analysis and a separate ActionableScore mechanism. The purpose of this report is to prioritize Linux kernel CVEs before manual review, identify cases that require prompt investigation, and support automatic closure of issues that are unlikely to have meaningful security impact. Published priority for this report: MODERATE REGULAR Manual review required: YES A detailed explanation of the methodology and priority rules is included at the end of this message. ====================================================================== AL-KERNEL CLASSIFICATION RESULT ====================================================================== CVE-2026-81010 MODERATE https://www.kernelcve.org/list/?q=CVE-2026-81010 CHECK WITH IMPACT FROM ORIG NN MODERATE Maybe valid. Check manually. Hints by AL-KERNEL: The best (paranoid) CVSS is 'AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H';CWE-703;CWE-362;*CWE-664;Other CVSS 'AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L';BEST CVSS score: '4.7';DESCR 'io_uring WAITID task_work can run through a fallback kworker path after the originating task can no longer accept queued task_work. In that fallback path io_uring marks the work as canceled through tw.cancel, but the old callback still entered __do_wait. waitid is task context dependent, so __do_wait performs child lookup relative to current and in this case current is the kworker rather than the submitting task. The completion path could also reach siginfo handling without the submitters userspace execution context. For the CVSS the PR:L is used because a local process is required to create io_uring WAITID requests and reach the cancellation fallback, even though no administrative privilege is required. The issue is not network reachable. Impact is mainly local denial of service or incorrect waitid completion behavior, with no concrete evidence of information disclosure or privilege escalation from the shown code path.';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Borderline / manual review recommended (with actual score 4) YES INIT SIMPLEFIX IO_URING DECREASED_TO_MODERATE_REGULAR_FROM_MODERATE7_BASED_ON_GUESSCVSS_AND_CIANNH YES NO checked ====================================================================== ACTIONABLESCORE ANALYSIS ====================================================================== ActionableScore=4 ActionableScoreLower=3 PrimitiveClass=CLASS_C RealUAF=NO HostAdminRequired=NO NamespaceScopedPrivilege=NO ImportantCandidate=NO ManualReview=RECOMMENDED AutoDowngradeAllowed=YES 1. ActionableScore * Raw conservative score: 3 * Conservative score: 3. No floor or cap applied. * Raw paranoid score: 4 * Paranoid score: 4. No floor or cap applied. * Final recommended bucket: **Borderline / manual review recommended**:: 2. Signal breakdown Conservative signals: * +1 Local unprivileged trigger. A local process can create io_uring WAITID requests. No host-admin privilege is shown as required. * +1 Class C invalid task-context behavior. The callback can run from a fallback kworker while still calling __do_wait(), which is explicitly task-context dependent and uses current. * +1 Local DoS or incorrect completion concern. The wrong current task and missing submitting userspace context can cause incorrect waitid behavior and unsafe completion handling, although a concrete memory corruption primitive is not established. Paranoid additional signal: * +1 Stronger availability concern from fallback kworker execution. The affected path combines canceled task_work, wrong current, __do_wait(), and siginfo completion without the submitter context. This is enough to keep it in manual-review territory, but not enough to score C/I or Important. Non-awarded signals: * RealUAF not awarded. The patch does not establish use-after-free or stale post-lifetime object use. * Concrete repeated release/refcount not awarded. There is no visible first release that can end lifetime followed by a second lifetime-mutating operation on the same dangling reference. * Controlled reclaim not demonstrated. * Arbitrary write not demonstrated. * Confidentiality and integrity not awarded. No disclosure path, protected-object access, or unauthorized modification primitive is shown. * Remote reachability not awarded. This is a local io_uring operation, not packet or network triggered. * Strong LPE not awarded. The bug class is context mismatch and cancellation handling, not a demonstrated privilege escalation primitive. * Extra availability not awarded beyond the same local DoS or incorrect-completion concern. * Race penalty not applied. The fallback cancellation condition is state dependent, but the evidence does not prove a narrow or externally uncontrollable timing race. Repeated-release/refcount checklist: * First release can end lifetime: not established. * Exact same reference survives to second release: not established. * Second operation is a lifetime/refcount mutation: not established. * Concrete repeated release/refcount +1 awarded: no. * Paranoid repeated-refcount leverage +1 awarded: no. * FLOOR 5 applied: no. 3. Reachability analysis The evaluated attacker is an ordinary local user or local process that can use io_uring and submit IORING_OP_WAITID. The vulnerable path is reached when task_work_add() can no longer queue work to the originating task and io_uring falls back to kworker execution with tw.cancel set. Host-admin-equivalent privilege is not required by the supplied evidence. Namespace-scoped privilege is not relevant because the trigger is not based on CAP_NET_ADMIN or namespace-owned objects. No prior host setup, special hardware, boot option, or sysctl prerequisite is established from the supplied patch. The issue is not network reachable. Race difficulty is not penalized because the problem is primarily cancellation and fallback execution context handling rather than a proven narrow timing race. 4. Primitive and severity interpretation The exact primitive is a task-context mismatch in io_uring WAITID cancellation handling. A canceled fallback task_work item can run from a kworker, but the old callback still enters __do_wait(), which performs child lookup relative to current and uses current->signal->wait_chldexit. In the fallback case current is the kworker, not the submitting task. This is not an active structured UAF and not fixed stale storage. It is a Class C invalid-state or DoS-style behavior. The demonstrated consequence is incorrect waitid processing and possible local availability impact. A speculative stronger consequence would require a separate memory corruption, disclosure, or authorization-bypass path, which is not shown. ImportantCandidate=NO because no Class A primitive, real UAF, repeated refcount mutation, controlled corruption, COW violation, or authorization boundary bypass is established. AutoDowngradeAllowed=YES because the unresolved evidence does not show meaningful exploitation leverage beyond local DoS or incorrect completion behavior. Likely operational severity is Borderline Moderate. It should be reviewed because io_uring task_work cancellation and kworker execution context bugs can have subtle side effects, but the supplied evidence does not justify Important-class treatment. 5. One-sentence report phrase io_uring WAITID canceled task_work could run in a fallback kworker context and incorrectly call __do_wait() relative to the wrong current task, causing local incorrect waitid behavior or denial of service without evidence of memory corruption or privilege escalation. 6. Manual review recommendation MANUAL CHECK RECOMMENDED Reason: the issue is local and appears DoS or correctness oriented, but io_uring cancellation plus wrong task context and skipped submitter userspace context is subtle enough to justify manual review before automatic closure. 7. Call-site confidence Call-site confidence: medium ====================================================================== UPSTREAM PATCH SUMMARY ====================================================================== Patch: io_uring/waitid: honor task_work cancellation Commit: 7bc98e2de8c58a2bfaf0f540eb096a386ecfc96c Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7bc98e2de8c58a2bfaf0f540eb096a386ecfc96c Commit description: io_waitid_cb() may run through the fallback task_work path when task_work_add() can no longer queue work to the originating task. The fallback runs from a kworker and io_uring marks such task work as canceled through tw.cancel. io_waitid_cb() currently ignores tw.cancel and calls __do_wait(). waitid is task-context dependent: __do_wait() performs child lookup relative to current, and the retry path also uses current->signal->wait_chldexit. If the callback runs from the fallback kworker, current is therefore not the task that submitted the request. Honor tw.cancel before entering __do_wait(). Complete the request with -ECANCELED and skip the siginfo copy, since canceled task work may run without the submitting task's userspace execution context. Keep the existing siginfo handling for normal waitid completion and explicit cancellation. Fixes: f31ecf6 ("io_uring: add IORING_OP_WAITID support") Cc: stable@vger.kernel.org Signed-off-by: Hui Su Link: https://patch.msgid.link/20260818103336.1922818-2-sh_def@163.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman Changed files: io_uring/waitid.c Diff excerpt: Not included in this email. See the upstream URL for the full patch. Full patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7bc98e2de8c58a2bfaf0f540eb096a386ecfc96c ====================================================================== DETAILED REPORT METHODOLOGY ====================================================================== The original Linux kernel CVE announcement for CVE-2026-81010 can be found here: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-81010 The original CVE announcement normally does not include a security-level estimate. In particular, it may not contain a CVSS assessment, an impact level, or enough information to determine whether the reported bug is a practically relevant security issue. One purpose of this parallel CVE list is to provide that missing technical and prioritization information. The original goal of the AL-KERNEL project was to prioritize Linux kernel CVE analysis automatically before manual review. The system can also help identify non-security issues that may be suitable for automatic closure. This report was generated by AL-KERNEL, an AI-assisted Linux kernel vulnerability analysis system developed by Alexander Larkin. The first analysis stage combines an autonomous classifier with additional LLM-based analysis. The autonomous classifier runs locally on a CPU and is based on a backpropagation neural network. Together, these mechanisms produce a technical vulnerability description, identify likely weakness types, estimate CVSS severity, and provide input for ActionableScore. Two CVSS estimates are retained because incomplete kernel vulnerability information often permits more than one defensible interpretation: Conservative CVSS vector: AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L The Best / paranoid CVSS vector: AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H The Best / paranoid CVSS score: 4.7 The conservative vector represents a lower-impact interpretation. The Best/paranoid vector intentionally represents a plausible upper-bound interpretation and should not automatically be treated as demonstrated real-world impact. CVSS may also need to be adjusted for a particular Linux deployment, because actual reachability, privileges, enabled kernel configuration, hardware, namespaces, exposed device nodes, and other environmental conditions can differ significantly between systems. A separate ActionableScore mechanism evaluates practical remediation urgency. Its analysis may include reachability, attack prerequisites, subsystem exposure, memory-corruption characteristics, denial-of-service reliability, and possible confidentiality, integrity, or privilege-escalation impact. Conservative ActionableScore: 3 Paranoid ActionableScore: 4 The final base severity is taken directly from the second tab-separated field of the AL-KERNEL classification result. ActionableScore does not replace or independently override that final AL-KERNEL decision, and if ActionableScore adjusted impact level of ALKERNEL, then you would see self-readable flags above like INCREASED_TO_HIGH_BASED_ON_ACTIONABLESCOREHIGHEREQTHAN7. For an AL-KERNEL result of MODERATE, this report uses the following additional presentation split: ActionableScore below 5 -> MODERATE REGULAR ActionableScore 5 or more -> MODERATE 7.0 The distinction between MODERATE REGULAR and MODERATE 7.0 makes it possible to identify Moderate issues that should receive manual analysis and fixes before lower-priority MODERATE REGULAR issues. In many cases, MODERATE REGULAR fixes may wait for a later rebase or routine update. There is one override in which MODERATE REGULAR becomes MODERATE 7.0 even when the ActionableScore is below 5. When the AL-KERNEL result contains the KPANIC flag, a MODERATE result is always presented as MODERATE 7.0. The KPANIC flag selected with few regexps without usage of AI at all, so it helps to detect cases when Kernel Crash happens and similar (to filter False-Negative results from the LLM usage). KPANIC indicates that a reliable kernel crash, kernel panic, or similarly serious kernel availability impact was identified by the classification workflow. AL-KERNEL base severity for this report: MODERATE KPANIC detected for this report: NO Published priority for this report (same as in Subject): MODERATE REGULAR These results are intended to support engineering triage. They are machine-generated estimates, and cases marked for manual review should be validated by a human security engineer before final disposition. For more info read docs linked from here: https://kernelcve.org/ (and you can submit you own patch there to generate such a report for non-existant CVE-id yet). Note that in many cases this AI tool selects higher severity, than real is (means you can expect Importants instead of Moderate 7.0 or Moderates 7.0 instead of regular Moderates). If you see such cases, please use reply email interface to add additional manual analyses info to this particular CVE. And please, please, let me know when you see Lows instead of Importants or Important instead of Low (because particular for such cases I need to tune this AI tool to make it better for this one and next similar). My contact email for such notifications is alexanjelausa@gmail.com (and both send reply to CVE record itself too and see "reply" button below for howto reply).