From 101f6859fac580ea7213a8a600602dcf4877848a Mon Sep 17 00:00:00 2001 From: Nicholas Barbier <140830771+nbarbier-265@users.noreply.github.com> Date: Thu, 20 Aug 2026 16:46:49 -0400 Subject: [PATCH 1/2] Recheck the cache before becoming the RTCache lookup writer A task that misses the cache can acquire the lockers write lock after the previous writer for the same key has already populated the cache and removed its lock. It then becomes a new writer and performs a lookup whose result is already cached. Recheck the cache under the lockers write lock before inserting a new CacheLock, the same double-checked pattern the waiting-reader path already uses after its lock is released. The window sits between two synchronous statements, so it cannot be exercised deterministically through the public API; the existing concurrency tests cover the changed path. Fixes #110 --- pingora-memory-cache/src/read_through.rs | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/pingora-memory-cache/src/read_through.rs b/pingora-memory-cache/src/read_through.rs index 96e4348e1..05914310d 100644 --- a/pingora-memory-cache/src/read_through.rs +++ b/pingora-memory-cache/src/read_through.rs @@ -191,6 +191,13 @@ where } } None => { + /* recheck the cache before becoming the writer: another lookup may have + * populated it and removed its lock between our initial miss and + * acquiring this write lock */ + let (result, _) = self.inner.get(key); + if let Some(result) = result { + return (Ok(result), CacheStatus::LockHit); + } let new_lock = CacheLock::new_arc(); let new_lock2 = new_lock.clone(); lockers.insert(hashed_key, new_lock2); From 5ec45082c5348b676e021bdff3874f3f06289ae9 Mon Sep 17 00:00:00 2001 From: Nicholas Barbier <140830771+nbarbier-265@users.noreply.github.com> Date: Thu, 20 Aug 2026 17:18:56 -0400 Subject: [PATCH 2/2] Ignore RUSTSEC-2026-0258 in cargo audit h2 0.3.27 comes in through the same legacy aws chain as the existing rustls-webpki ignores: dial9-tokio-telemetry -> aws-sdk-s3-transfer-manager -> aws-config -> aws-smithy-http-client, which still uses hyper 0.14. The advisory's only fix is h2 >= 0.4.16 and no 0.3.x patch exists, so this cannot be resolved from this workspace's manifests. The vulnerable code needs a malicious HTTP/2 peer; in this chain h2 is only a TLS client to AWS endpoints. Every CI run has failed the cargo audit step since the advisory was published on 2026-08-17. --- .cargo/audit.toml | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/.cargo/audit.toml b/.cargo/audit.toml index e8a430531..9a92341ea 100644 --- a/.cargo/audit.toml +++ b/.cargo/audit.toml @@ -1,12 +1,14 @@ -# Advisories against rustls-webpki 0.101.7, pulled in transitively by -# aws-sdk-s3-transfer-manager through the legacy rustls 0.21 chain used by -# dial9's worker-s3 feature. No patch exists in 0.101.x; not reachable in -# our usage because this is TLS client use only and does not parse CRLs. -# Remove once the upstream aws-s3-transfer-manager-rs fix ships. +# Advisories against rustls-webpki 0.101.7 and h2 0.3.x, pulled in transitively +# by aws-sdk-s3-transfer-manager through the legacy hyper 0.14 / rustls 0.21 +# chain used by dial9's worker-s3 feature. No patches exist in those release +# lines; not reachable in our usage because this is TLS client use only against +# trusted AWS endpoints, does not parse CRLs, and is not exposed to untrusted +# HTTP/2 peers. Remove once the upstream aws-s3-transfer-manager-rs fix ships. [advisories] ignore = [ "RUSTSEC-2026-0098", # rustls-webpki: URI name constraints incorrectly accepted "RUSTSEC-2026-0099", # rustls-webpki: name constraints accepted for wildcard certs "RUSTSEC-2026-0104", # rustls-webpki: reachable panic in CRL parsing + "RUSTSEC-2026-0258", # h2 0.3: unbounded empty DATA frames ]