exploiting-integer-overflow-vulnerabilities

name	exploiting-integer-overflow-vulnerabilities
description	Methodology for finding and exploiting integer overflow, underflow, truncation, and signedness bugs in native code during authorized engagements, focusing on how wrapped arithmetic in size/length calculations leads to undersized allocations, oversized copies, length-check bypasses, and downstream heap/stack overflows.
domain	cybersecurity
subdomain	binary-exploitation
tags	["binary-exploitation","integer-overflow","exploit-development"]
version	1.0
author	xalgorix
license	Apache-2.0

Exploiting Integer Overflow Vulnerabilities

When to Use

• During authorized assessments of native code (C/C++/Rust/Go) where attacker-controlled integers feed size, length, count, index, or offset calculations.
• When an allocation size is computed from arithmetic (count * elem_size, len - header, size + padding) that can wrap, producing an undersized buffer later written with the logical (un-wrapped) size — a classic integer-overflow-to-heap-overflow chain.
• When a length/bounds check uses a narrow type (e.g. 1-byte size field) that can be overflowed to bypass validation while the real copy uses a larger value.
• When signed/unsigned confusion causes a negative input to be treated as a huge positive size.

Critical: Concepts/Steps Most Often Missed

• The overflow itself is rarely the impact — find the dangerous downstream use. An int wrap is only exploitable when the wrapped value sizes an allocation/copy/index. Always trace the tainted integer to a malloc, memcpy, read, loop bound, or array index.
• Truncation across type widths. uint32_t product = (uint32_t)(count * elem_size) can wrap to a tiny value while a separate size_t to_copy = count * elem_size keeps the full value — allocation is small, copy is huge. Watch every cast to a narrower type.
• Underflow on subtraction is just as dangerous. size_t payload = total_len - HEADER with total_len < HEADER underflows to a near-SIZE_MAX value, turning a "shrink" into an unbounded copy.
• Signedness. A signed int read with scanf("%d") then cast to unsigned makes negatives become large positives, defeating if (x > LIMIT) checks.
• Alignment/rounding re-introduces overflow after an initial guard. Custom allocators that pass an initial wrap check then do total += (8 - total) % total can wrap again for values near SIZE_MAX, yielding a tiny chunk (e.g. CVE-2025-54957).
• Go/Rust wrap silently in release/normal builds. Go has no overflow panic by default; instrument with go-panikint; Rust wraps in release unless overflowing_*/checked arithmetic is used.

How to CONFIRM

Instrument and observe the wrap directly. In C, compile a probe with /UBSan () to get a runtime report at the exact operation. In a debugger, set a breakpoint after the size computation and inspect the register/variable: confirm the allocation size is small (e.g. 32) while the copy length is huge (e.g. ). The exploit is confirmed when the undersized buffer's neighbor (e.g. flag, chunk metadata) is overwritten — verify the target field changed and the gated/privileged path executes.