SQUID-2023:11 Denial of Service in Cache Manager

A trusted client (one permitted by the Cache Manager ACL) sends a request that causes the Cache Manager to generate an error response. The `CacheManager::start()` function [ref_id=2][ref_id=3] sets `entry->expires = squid_curtime` after `errorAppendEntry()` has already set the expiration, leaving the StoreEntry in an inconsistent state. This can lead to a use-after-free or NULL-pointer dereference when the error page is being delivered, crashing Squid (Denial of Service). The precondition is that the client must be allowed to access the Cache Manager; the advisory suggests using `http_access deny manager` as a workaround.

The bug is in `CacheManager::start()` in `src/cache_manager.cc`. The function calls `errorAppendEntry()` to set the StoreEntry expiration, but then immediately overwrites `entry->expires = squid_curtime`, creating a race window where the StoreEntry pointer can become stale. The advisory [ref_id=1] also traces a crash path through `clientReplyContext::pushStreamData()` → `clientStreamCallback()` → `clientSocketRecipient()` → `Http::One::Server::handleReply()` where a NULL `rep` pointer triggers an assertion failure.

The patch [ref_id=2][ref_id=3] removes the single line `entry->expires = squid_curtime;` from `CacheManager::start()` after the call to `errorAppendEntry()`. The commit message explains that `errorAppendEntry()` already sets the entry expiration via `StoreEntry::storeErrorResponse()` → `StoreEntry::negativeCache()`, so the subsequent overwrite is both redundant and dangerous: it creates a window where the StoreEntry pointer can become stale, leading to the use-after-free or assertion failure. The fix simply lets `errorAppendEntry()` manage the expiration as intended.