Multiple places in ServerRuntime.AsyncResponder check conditions in a read lock, release the read lock, acquire a write lock, and then make changes. Between releasing the read lock and acquiring the write lock changes could happen that would make the checks done in the read lock no longer valid. Below is an example of what appears to be a race condition where resume and cancel operations can both run.
- Thread1 calls resume() and here finds state is SUSPENDED and continues.
- Thread2 calls cancel() and here find state is SUSPENDED and continues.
- Thread1 releases read lock
- Thread 2 release read lock
- Thread1 obtains the write lock
- Thread1 sets state to RESUMED here
- Thread1 release the write lock
- Thread2 obtains the write lock
- Thread2 sets state to RESUMED and sets canceled to true here. At this point Thread1 has already changed the state to RESUMED, so it does not seem like it should proceed.
- Thread2 releases the write lock
- Thread1 initiates resumption here
- Thread2 initiates cancelation here
Only looked at this code in isolation, so not sure if there are other mitigating factors outside this code that would handle this race condition.
Multiple places in ServerRuntime.AsyncResponder check conditions in a read lock, release the read lock, acquire a write lock, and then make changes. Between releasing the read lock and acquiring the write lock changes could happen that would make the checks done in the read lock no longer valid. Below is an example of what appears to be a race condition where resume and cancel operations can both run.
Only looked at this code in isolation, so not sure if there are other mitigating factors outside this code that would handle this race condition.