Squid before 4.13 and 5.x before 5.0.4 allows a trusted peer to perform Denial of Service by consuming all available CPU cycles during handling of a crafted Cache Digest response message. This only occurs when cache_peer is used with the cache digests feature. The problem exists because peerDigestHandleReply() livelocking in peer_digest.cc mishandles EOF.
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 |
|---|---|---|---|
| Squid | Squid-cache | 3.0 (including) | 4.13 (excluding) |
| Squid | Squid-cache | 5.0.1 (including) | 5.0.4 (excluding) |
| Red Hat Enterprise Linux 7 | RedHat | squid-7:3.5.20-17.el7_9.4 | * |
| Red Hat Enterprise Linux 8 | RedHat | squid:4-8030020200828070549.30b713e6 | * |
| Squid | Ubuntu | devel | * |
| Squid | Ubuntu | focal | * |
| Squid | Ubuntu | groovy | * |
| Squid | Ubuntu | hirsute | * |
| Squid | Ubuntu | trusty | * |
| Squid3 | Ubuntu | bionic | * |
| Squid3 | Ubuntu | precise/esm | * |
| Squid3 | Ubuntu | trusty | * |
| Squid3 | Ubuntu | xenial | * |
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.