Submission File: ES2605-6b802369-new-reliance-asynchronous-work-cancellation-as-resource-lifetime-barrier.txt
ID: ES2605-6b802369
SUBMISSION DATE: 2026-05-28 08:09:31
NAME: Reliance on Asynchronous Work Cancellation as Resource Lifetime Barrier
DESCRIPTION:
This weakness arises from conflating two distinct meanings of the
cancellation operation. The first meaning is the stopping of any instance
that has already been queued or is currently executing. The second meaning
is the guarantee that no further execution will occur through any path.
Many standard cancellation APIs provide only the former. Even after the
cancellation call returns, if a concurrent execution path (such as deferred
processing in interrupt context, or another thread) reschedules the same
work item before the resource is released, the work item becomes pending
again. When the resource release code treats the cancellation return as the
end of the item's lifetime, the work item can be queued again within the
time window between cancellation and release, and the callback then
executes while still referencing the released resource.
If the memory of the affected resource has already been reallocated to
another object by the time the callback executes, consequences may include
unintended writes to or reads from the object now occupying the reallocated
region, control flow hijacking via a function pointer within the callback
structure, or information disclosure. The resulting impact is similar to
that of CWE-416 and CWE-825. When triggerable from unprivileged user space,
the weakness can lead to privilege escalation; when reachable over the
network, it can lead to remote code execution.
This weakness occurs in deferred dispatch mechanisms where software
explicitly performs schedule, arm, or queue calls (for example, kernel
workqueues, tasklets, software timers, deferred procedure calls, and BSD
taskqueues). Some systems provide a separate API that blocks future
scheduling itself, but when the API names corresponding to the two meanings
(stopping the current instance and blocking future execution) are adjacent
within the same family of functions, incorrect assumptions readily form.
Submission File: ES2605-6b802369-new-reliance-asynchronous-work-cancellation-as-resource-lifetime-barrier.txt
ID: ES2605-6b802369
SUBMISSION DATE: 2026-05-28 08:09:31
NAME: Reliance on Asynchronous Work Cancellation as Resource Lifetime Barrier
DESCRIPTION:
This weakness arises from conflating two distinct meanings of the
cancellation operation. The first meaning is the stopping of any instance
that has already been queued or is currently executing. The second meaning
is the guarantee that no further execution will occur through any path.
Many standard cancellation APIs provide only the former. Even after the
cancellation call returns, if a concurrent execution path (such as deferred
processing in interrupt context, or another thread) reschedules the same
work item before the resource is released, the work item becomes pending
again. When the resource release code treats the cancellation return as the
end of the item's lifetime, the work item can be queued again within the
time window between cancellation and release, and the callback then
executes while still referencing the released resource.
If the memory of the affected resource has already been reallocated to
another object by the time the callback executes, consequences may include
unintended writes to or reads from the object now occupying the reallocated
region, control flow hijacking via a function pointer within the callback
structure, or information disclosure. The resulting impact is similar to
that of CWE-416 and CWE-825. When triggerable from unprivileged user space,
the weakness can lead to privilege escalation; when reachable over the
network, it can lead to remote code execution.
This weakness occurs in deferred dispatch mechanisms where software
explicitly performs schedule, arm, or queue calls (for example, kernel
workqueues, tasklets, software timers, deferred procedure calls, and BSD
taskqueues). Some systems provide a separate API that blocks future
scheduling itself, but when the API names corresponding to the two meanings
(stopping the current instance and blocking future execution) are adjacent
within the same family of functions, incorrect assumptions readily form.