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.
Rule Explorer
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.
- Public rules
- 4797
- Downloads
- 7.4M
- Verified
- 4797
- Authors
- 2
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.
Passing `-1` as an application error code to `ngtcp2_ccerr_set_application_error` or `ngtcp2_connection_close_error_set_application_error` causes an implicit cast to `UINT64_MAX`. This exceeds the maximum value for a QUIC variable-length integer (62 bits) and will cause an assertion failure in libngtcp2 during serialization. Pass a valid application error co
A numeric value is truncated using `.intValue()` before its bounds are checked. If the original number (e.g. a 64-bit `Long`) is outside the 32-bit integer range, it can silently wrap around. This wrapped value may evade bounds checking constraints, allowing the system to enter an unsafe or unbounded state. Perform bounds validation against the original un-t
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.
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
A boundary validation check comparing a potentially signed integer against `SIZE_MAX / $Y` without explicitly casting it to an unsigned integer format was detected. Due to implicit C++ type promotion rules, the bounds condition may evaluate unsafely depending on integer widths, potentially allowing out-of-bounds large integer sizes to bypass validation. This
A potentially signed value is compared directly against an unsigned maximum limit (`SIZE_MAX / $SIZE`). This can lead to type promotion issues where the signed integer is implicitly cast, potentially enabling integer overflows to bypass bounds checks. Explicitly cast the signed value to an unsigned integer type before making the comparison.
Implicit mixed-type comparison between a signed integer and an unsigned maximum bound can trigger compiler-dependent type promotion issues, resulting in unreliable overflow checks. Explicitly cast the signed integer to an unsigned type (e.g., `uint64_t`) before the comparison.
A 64-bit integer from sqlite3_value_int64() is passed to sqlite3_malloc(), which only accepts a 32-bit int. Integer truncation can result in an undersized buffer allocation leading to heap buffer overflow. Use sqlite3_malloc64() instead.
A coordinate is capped against `SW_FT_INT_MAX` or `FT_INT_MAX` instead of 32767 before being assigned to a 16-bit short value (like `SW_FT_Span.y`). This leads to integer truncation, potentially resulting in out-of-bounds memory accesses and heap buffer overflows. Cap the coordinate at 32767 instead.
A signed integer is compared against an unsigned size limit (SIZE_MAX / expression) without explicitly casting the signed integer. This may cause implicit signed-to-unsigned conversions to behave unexpectedly, allowing memory bounds checks to be bypassed. Always cast the signed integer to an unsigned type (e.g., static_cast<uint64_t>) before making the size
Comparing a signed element count to an unsigned size limit (e.g., `SIZE_MAX / size`) without an explicit cast can cause improper type promotion or truncation. This allows malicious inputs to bypass integer overflow protection on certain architectures, leading to undersized memory allocations and subsequent out-of-bounds read/write accesses. Explicitly cast t