Skip to content

fix: avoid use-after-free in rate_limiter periodic cleanup - #70

Draft
cursor[bot] wants to merge 1 commit into
masterfrom
cursor/critical-bug-management-fc6c
Draft

fix: avoid use-after-free in rate_limiter periodic cleanup#70
cursor[bot] wants to merge 1 commit into
masterfrom
cursor/critical-bug-management-fc6c

Conversation

@cursor

@cursor cursor Bot commented Aug 2, 2026

Copy link
Copy Markdown
Contributor

Bug and impact

http::middleware::rate_limiter::check_limit could use-after-free on every 1000th call that removed an empty key from its std::flat_map. That is undefined behavior in production rate limiting (crash / memory corruption under sustained traffic).

Root cause

check_limit held auto& key_requests = requests[key], then ran std::erase_if to drop empty entries. flat_map erase invalidates all references, so the following size() / push_back operated on a dangling reference whenever cleanup removed anything (e.g. an orphan key left by max_requests == 0).

Fix

Record the allow/deny decision and push_back before erase_if, then return the saved result.

Validation

  • Added regression: rate_limiter check_limit survives periodic empty-key cleanup
  • tools/CB.sh debug test rate_limiter → 4/4 passed (1002 assertions)
Open in Web View Automation 

check_limit held a reference into std::flat_map requests[key], then
erase_if'd empty entries on every 1000th call. flat_map erase
invalidates all references, so the following size()/push_back was UAF
whenever cleanup removed anything. Record the allow/deny decision
before cleanup; add a regression covering the orphan-key path.

Co-authored-by: Kaius  Ruokonen <ruoka@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant