D3-IRV Integer Range Validation: Overflow Checks, Compiler Options and Tests

An integer that silently overflows, wraps or truncates can turn a size check into a heap overflow, a quota into an unlimited allowance, or a loop into a hang. MITRE D3FEND names the countermeasure Integer Range Validation (D3-IRV) and defines it as "Ensuring that an integer is within a valid range." It sits under the Harden tactic as a child of Source Code Hardening (D3-SCH), and the digital artefact it hardens is a Mathematical Function. This card explains what the check involves, where developers and toolchains implement it in C, C++ and Rust, how to prove that it is in place, and where it falls short. It is for application security engineers, developers of native code and the people who run secure build pipelines.

Key takeaways

• It is a coding control, not a product. D3-IRV is applied in source code: check the value of an integer before or after an operation so the result stays in a valid range.
• D3FEND maps no ATT&CK techniques to it. As of D3FEND 1.6.0 the technique page lists no related offensive techniques, so its value comes from the weaknesses it prevents, chiefly CWE-190 Integer Overflow or Wraparound.
• Valid range means more than the type limit. D3FEND notes a range can be defined by the language, the data type or logical constraints: a length must also fit the buffer, a count must fit the business rule.
• Use checked arithmetic, not hand-written tricks. Compiler builtins such as __builtin_mul_overflow, C23 ckd_mul and Rust's checked_* methods compute the true result and report overflow without undefined behaviour.
• Prove it with sanitizers and fuzzing. UndefinedBehaviorSanitizer integer checks plus fuzzing at boundary values show whether the checks exist on the paths that matter.

D3-IRV at a glance

What it prevents

D3FEND's article says that checking an integer's value "helps prevent integer overflow, wraparound, and logical errors." MITRE's CWE entry for CWE-190 lists the consequences: crashes and resource exhaustion, data and memory corruption, buffer overflows that can lead to code execution, loops that end early, late or never, and wrong security decisions when quotas, allocation limits or time values overflow. CWE-680 Integer Overflow to Buffer Overflow describes the classic chain: a size calculation such as count * element_size wraps to a small number, the allocation succeeds, and the copy that follows writes past the end.

For the wider family of memory bugs these lead to, see the Memory Corruption Vulnerabilities Guide.

Where it is implemented

D3-IRV lives in code and in the toolchain. The table lists language and compiler features that implement or enforce it; it describes them, it does not rank them.

Language-level guidance is in the C and C++ Secure Coding Guide, and the case for moving new components to safer languages is in the Memory-Safe Languages Guide.

Implementation steps

1. Find the arithmetic that matters. SEI CERT INT32-C gives priority to values from untrusted sources used in pointer arithmetic, array indexing, variable-length array sizes and size_t arguments. Start with parsers, decoders, network protocol handlers and allocation size calculations.
2. Define each valid range. Write down the minimum and maximum for each field from the protocol or business rule, not only the type limit. A 32-bit length field may be valid only up to the maximum message size.
3. Validate on entry. Reject out-of-range input at the trust boundary, before it reaches arithmetic. CWE-190 recommends checking both minimum and maximum bounds.
4. Use checked operations inside. Replace raw a * b in size calculations with a checked multiply and handle the overflow result as an error. In Rust, use checked_mul where wrapping would be wrong.
5. Check conversions. Before narrowing or changing sign, test the value against the destination type range.
6. Turn on compiler warnings. CWE-190 advises examining compiler warnings, such as signed and unsigned mismatches, and fixing those with security implications. Gate new warnings in CI.
7. Roll out gradually. Add sanitizer builds to CI first in report mode, fix findings, then make them failing checks. A change that rejects input that used to be accepted can break clients, so release behind a feature flag where possible and keep the previous build ready to redeploy.

How to verify it works

• Sanitizer test runs: build test and fuzz targets with -fsanitize=signed-integer-overflow and, where wraparound is never intended, -fsanitize=unsigned-integer-overflow. Clang's documentation notes that unsigned overflow is not undefined behaviour but is often unintentional, and that -fsanitize=undefined does not include it, so enable it explicitly.
• Boundary tests: unit tests at 0, 1, the maximum, the maximum minus one, the minimum, -1 and the INT_MIN / -1 case for every validated field.
• Fuzzing: fuzz parsers with length and count fields so values near the bounds are generated. See the Fuzzing Guide.
• Code review queries: search for allocation calls whose size argument contains an unchecked multiply, and for casts from wide to narrow integer types on input-derived values.

Limits, bypasses and failure patterns

• Check written in an overflowing way: a test such as if (a + b < a) on signed integers relies on undefined behaviour, and the compiler may remove it. Use a precondition test or a builtin.
• Check placed after the damage: validating the result after it has been used to allocate or index does not help. D3FEND allows checks before or after an operation, but after-checks must come before any use.
• Type range instead of logical range: a value that fits in uint32_t can still be far larger than the buffer it describes. The considerations in D3FEND call out logical constraints for this reason.
• Wrap-on-overflow flags taken as a fix: GCC's -fwrapv makes signed overflow defined modulo arithmetic, which removes undefined behaviour but not the wrong result. -ftrapv traps at run time, and SEI CERT treats it as a detection behaviour, not a compliant solution.
• Release builds without checks: Rust overflow checks are on in debug builds; if a release profile leaves them off, overflow that tests would have caught can pass. Use explicit methods where it matters.
• Sanitizer runtime in production: Clang states the full UBSan runtime is meant for testing. For production hardening it recommends the minimal runtime or trap mode (-fsanitize-minimal-runtime, -fsanitize-trap).

Related ATT&CK techniques

D3FEND 1.6.0 lists no ATT&CK techniques for D3-IRV. In NHI Mgmt Group's view, not D3FEND's mapping, integer overflow bugs are a common root cause in the exploitation techniques T1190 Exploit Public-Facing Application, T1203 Exploitation for Client Execution and T1068 Exploitation for Privilege Escalation, which is why D3-IRV belongs alongside the run-time protections in M1050 Exploit Protection.

Framework mapping

The parent, Source Code Hardening, also covers D3-PV Pointer Validation and D3-VTV Variable Type Validation. The wider framework is in the MITRE D3FEND Guide.

Practitioner checklist

• List parsers, decoders and allocation sites that do arithmetic on untrusted integers.
• Document a minimum and maximum for every input integer from the specification.
• Reject out-of-range values at the trust boundary.
• Use checked arithmetic (builtins, C23 ckd_*, Rust checked_*) for size and index calculations.
• Range-test before every narrowing or sign-changing conversion.
• Run UBSan integer checks, including unsigned overflow where wraparound is never intended, in CI.
• Fuzz every parser with values at and beyond the bounds.
• Track CWE-190, CWE-191 and CWE-680 findings to closure.

Standards and references

• MITRE D3FEND: Integer Range Validation (D3-IRV)
• MITRE CWE: CWE-190 Integer Overflow or Wraparound
• SEI CERT C Coding Standard: INT32-C Signed integer overflow
• SEI: SEI CERT C Coding Standard (2016 edition)
• GCC: Built-in Functions to Perform Arithmetic with Overflow Checking
• LLVM: Clang UndefinedBehaviorSanitizer
• Rust: The Rust Reference, Operator expressions (overflow)
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SI-10, SA-11)

Related NHI Mgmt Group resources: Secure Coding Guide · C and C++ Secure Coding Guide · CWE Top 25 Guide · Fuzzing Guide · MITRE D3FEND Guide