Add input size limits to prevent exponential computation#505
Open
rbtying wants to merge 3 commits into
Open
Conversation
…ation The unauthenticated /api/rpc endpoint accepts DecomposeTrickFormat requests with attacker-controlled TrickUnit count values. The find_tuple_partitions function computes all integer partitions recursively, which grows super-exponentially (p(100) ≈ 190M). Large count values exhaust CPU/memory, and stack overflows poison global mutex caches permanently. Changes: - Add MAX_DECOMPOSITION_SIZE (54) bound in full_decomposition_ordering to cap partition computation at one full deck size - Add input validation in decompose_trick_format RPC handler to reject trick formats exceeding the maximum size before processing - Replace .lock().unwrap() with .lock().unwrap_or_else(|e| e.into_inner()) on all three global cache mutexes to recover from poisoned state https://claude.ai/code/cse_018crD7az1p5jRzxzCwqMQuP
54 was based on deck size, but the relevant bound is num_decks (max players*2), which caps how many copies of a single card can exist. 20 covers even 10-player games while keeping partition counts trivial (p(20)=627 vs p(54)≈219K). https://claude.ai/code/cse_018crD7az1p5jRzxzCwqMQuP
Provides more headroom for games with many players/decks while p(32)=8349 remains computationally trivial. https://claude.ai/code/cse_018crD7az1p5jRzxzCwqMQuP
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR adds safeguards to prevent algorithmic complexity attacks by introducing maximum size limits for card decomposition operations. The changes protect against super-exponential blowup in partition computation while maintaining normal functionality for reasonable inputs.
Key Changes
MAX_DECOMPOSITION_SIZEconstant (20 cards) inordered_card.rsto cap inputs tofind_tuple_partitions, preventing exponential growth in partition enumeration (p(20)=627 vs p(100)≈190M)full_decomposition_orderingthat returns trivial decomposition (all singles) for inputs exceeding the limitMAX_TRICK_FORMAT_SIZEconstant (20 cards) inwasm-rpc-impl/lib.rsto validate trick format sizes at the API boundarydecompose_trick_formatthat rejects requests with trick formats exceeding the maximum sizeunwrap_or_else(|e| e.into_inner())instead ofunwrap(), allowing recovery from poisoned locksImplementation Details
FULL_DECOMPOSITION_CACHE,GROUP_CACHE,SEQUENTIAL_ASSIGNMENT_CACHE) now use consistent error handlinghttps://claude.ai/code/session_018crD7az1p5jRzxzCwqMQuP