gssproxy (aka gss-proxy) before 0.8.3 does not unlock cond_mutex before pthread exit in gp_worker_main() in gp_workers.c. NOTE: An upstream comment states We are already on a shutdown path when running the code in question, so a DoS there doesnt make any sense, and there has been no additional information provided us (as upstream) to indicate why this would be a problem.
The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
| Name | Vendor | Start Version | End Version |
|---|---|---|---|
| Gssproxy | Gssproxy_project | * | 0.8.3 (excluding) |
| Gssproxy | Ubuntu | bionic | * |
| Gssproxy | Ubuntu | groovy | * |
| Gssproxy | Ubuntu | hirsute | * |
| Gssproxy | Ubuntu | impish | * |
| Gssproxy | Ubuntu | kinetic | * |
| Gssproxy | Ubuntu | lunar | * |
| Gssproxy | Ubuntu | mantic | * |
| Gssproxy | Ubuntu | trusty | * |
Locking is a type of synchronization behavior that ensures that multiple independently-operating processes or threads do not interfere with each other when accessing the same resource. All processes/threads are expected to follow the same steps for locking. If these steps are not followed precisely - or if no locking is done at all - then another process/thread could modify the shared resource in a way that is not visible or predictable to the original process. This can lead to data or memory corruption, denial of service, etc.