Search the public rule index by CVE, GHSA, CWE, language, framework, author, or rule slug. Filter by language, framework, severity, confidence, license, and validation status.
Resetting negative byte lengths to zero in crypto or buffer pool operations without enforcing upper bounds or throwing errors allows integer overflow/coercion values to corrupt pool offsets and generate deterministic output. Validate bounds and throw a RangeError for invalid byte lengths.
Array or collection multiplication capacity is computed directly from 32-bit multiplication without checking for integer overflow or enforcing maximum element/iteration limits. This can lead to integer overflow or denial of service through unbounded memory allocation.
Manual PMR allocate call with multiplication by sizeof(...) can lead to integer overflow and heap buffer allocation of undersized memory. Prefer using RAII containers (such as std::vector with polymorphic_allocator) or validating bounds before allocating.
64-bit chunk.unpacked_size is passed to internal_decode_alloc_buffer without checking if it exceeds size_t capacity on 32-bit architectures, which can lead to integer truncation and out-of-bounds heap operations.
Scratch buffer size computed as a 64-bit integer is passed directly to internal_decode_alloc_buffer without checking for size_t integer truncation. On 32-bit systems (ILP32), this can result in an undersized buffer allocation and subsequent heap-based buffer overflow.
Potential 32-bit integer overflow in 2D coordinate pointer calculation. Using 32-bit signed integers for dimension variables and loop indices when computing buffer offsets can overflow with large dimensions. Use `int64_t` or `size_t` for dimensions and loop counters.
Accumulating buffer sizes in a loop using `+` or `+=` without overflow checks can lead to integer overflow. If the result is passed to an allocator, an undersized buffer is created, leading to a heap buffer overflow. Use sizes like `size_t` and safe integer arithmetic constructs like `INT_ADD_OK` to prevent overflow.
Adding pagination offset and limit directly without bounds or integer overflow checks can wrap around to a negative number. This bypasses naive upper-bounds checking and can cause out-of-bounds panics if used to slice an array. Clamp offset and limit values safely before addition.
Calculated frame payload buffer size is reallocated without verifying it against a maximum allowed size limit, which may allow excessive memory allocation or denial of service.
Unchecked repeated left shift loop rounding up to a power of two can overflow to zero when the input exceeds the highest power of two, causing an infinite loop (CWE-835 / CWE-190). Validate the input upper bound or ensure the accumulator cannot wrap around.
Variable-length frame header accumulation occurs without validating against maximum length limits, which can cause integer precision loss or uncontrolled resource usage.
A size value is explicitly cast to `int` before being added to a base offset in a bounds check. If the size is large enough (> 0x7FFFFFFF), it will wrap around to a negative number, potentially bypassing the bounds check completely. Validate the uncasted variable bounds against the boundary limits before performing this truncation.
Multiplication of integers compared against `cap()` or `len()` without expanding to a 64-bit integer type can cause integer overflow on 32-bit architectures. An attacker controlling the variables can trigger an overflow that wraps to a negative number, bypassing length or capacity checks and potentially causing out-of-bounds panics. Cast the multiplication o
An allocation size calculation is stored in a 32-bit (or smaller) integer variable. This can cause an integer overflow or silent truncation (if `sizeof` or other 64-bit types are involved). A wraparound leads to allocating an unexpectedly small buffer, which can cause a heap-based buffer overflow when data is written to it. Ensure allocation sizes are typed
Use of strict greater-than comparison for circular/wrapping window indices causes stream stalling and DoS upon index wraparound. Use inequality check (`!=`) instead.
An arithmetic operation evaluating before a type cast can cause an integer overflow. When calculating values of smaller types (like `byte` or `uint32`) before casting them to `int`, the arithmetic might exceed the maximum capacity of the smaller type and wrap around. This causes the subsequent bound checks to evaluate an incorrect, significantly smaller valu
Calling `decNumberFromString` with an unbounded string can lead to an integer overflow in the underlying decNumber library when parsing extremely long numeric literals. This can subsequently result in Out-of-Bounds memory writes. Ensure the string length is strictly validated against a maximum bound before parsing.
A static struct pointer is initialized to NULL and populated via a separate initialization function, creating a per-translation-unit accessor/dispatch table. When table entries use per-translation-unit const struct instances as type or mode tokens compared by pointer identity, cross-shared-library comparisons silently return false, selecting the wrong conver
Capacity calculations using unchecked arithmetic (`+`, `*`) can overflow, causing insufficient allocation and potential out-of-bounds access. If the buffer is unexpectedly truncated, subsequent operations assuming un-wrapped dimensions can trigger Undefined Behavior. Use `checked_add` and `checked_mul` to compute buffer dimensions safely securely.
Checking for integer overflow after a multiplication has occurred can lead to undefined behavior if the variables are signed. Modern compilers may optimize away these checks since signed integer overflow is undefined. To prevent this, verify that the operation will not overflow before performing it, using division (e.g., `if (X != 0 && Y > INT_MAX / X)`).
Directly casting the result of `atoi()` to a 16-bit integer (like `unsigned short`) can lead to integer truncation if the parsed value exceeds 65535. This type of truncation in port parsing is a common cause of Server-Side Request Forgery (SSRF) port confusion vulnerabilities. Ensure the parsed integer is bounds-checked before being cast, for example by usin
A signed integer is checked for negativity and then compared against a division (typically representing an upper capacity limit like SIZE_MAX / size) without an explicit cast. This can cause signed/unsigned type promotion issues, leading to potential integer overflows or critical static analyzer warnings. Explicitly cast the signed integer to an unsigned typ
Implicitly comparing a signed integer with a size division (like `SIZE_MAX / element_size`) can lead to signedness/promotion mismatches on mixed-bit architectures (e.g., 32-bit `size_t` vs 64-bit signed int). This can unexpectedly evaluate to false and bypass memory allocation overflow checks. Explicitly cast the signed integer to an unsigned 64-bit type (e.
A potentially signed integer is compared against an overflow threshold derived from SIZE_MAX, without an explicit cast. This implicit signed-to-unsigned conversion can lead to unsafe evaluations of negative boundaries or trigger compiler warnings. Explicitly cast the signed variable sequentially to an unsigned type (e.g., `static_cast<uint64_t>(...)`) before
