Integer Overflow in Rust: How Unchecked Addition Can Bypass File Size Limits

Introduction

Rust is celebrated for its memory safety guarantees — no null pointer dereferences, no buffer overflows, no use-after-free bugs. But "memory safe" doesn't mean "numerically safe." A subtle and dangerous class of bugs can still sneak through: integer overflow.

This post dives into a real-world vulnerability found in a Rust file transfer receiver where a single unchecked += operation could allow an attacker to feed unlimited data into a system that believed it was enforcing size limits. We'll break down exactly how it works, why Rust's release mode makes it worse, and how a one-line fix closes the door.

Whether you're new to Rust or a seasoned systems programmer, this vulnerability is a valuable reminder: safe memory management and safe arithmetic are two different things.

The Vulnerability Explained

What Went Wrong

In the file transfer receiver (src/transfer/receiver.rs), the code tracked how many bytes had been received from a sender using a running total:

// The vulnerable code
self.bytes_received += n;

Simple, right? The problem is what happens when bytes_received gets very, very large.

Rust's Debug vs. Release Mode Behavior

Here's the critical detail that makes this dangerous:

• In debug builds, Rust panics on integer overflow. Your program crashes with a clear error message.
• In release builds (cargo build --release), integer overflow silently wraps around — just like C and C++.

This is a deliberate performance trade-off documented by the Rust team, but it means production code is vulnerable in ways that testing (usually done in debug mode) will never catch.

When a u64 value exceeds its maximum (18,446,744,073,709,551,615), it wraps back to 0. When a usize on a 64-bit system does the same, the accumulated byte counter suddenly looks tiny — even though gigabytes or terabytes of data may have already been processed.

How an Attacker Exploits This

Here's the attack scenario, step by step:

1. Attacker initiates a file transfer, advertising a file size just under the system's maximum allowed limit (e.g., MAX_SIZE - 1 bytes).
2. The receiver accepts the transfer because the advertised size passes validation.
3. The attacker sends data in chunks, far exceeding the advertised size.
4. The bytes_received counter accumulates until it approaches u64::MAX.
5. Overflow occurs — the counter wraps around to a small value (e.g., near 0).
6. Size limit checks now pass again, because the wrapped value appears to be well within bounds.
7. The attacker continues sending data indefinitely, exhausting memory, disk space, or CPU — a classic resource exhaustion / denial-of-service attack.

bytes_received progression (u64):
  0 → 1,000,000 → ... → 18,446,744,073,709,551,615 → 0 (OVERFLOW!)
                                                         ^
                                                   Size check passes again!

Real-World Impact

• Denial of Service (DoS): Unlimited data floods the receiver, consuming memory and disk.
• Security Bypass: Any downstream logic gated on bytes_received (logging, billing, rate limiting) can be fooled.
• Data Integrity Issues: Systems that trust the byte counter for integrity checks may produce incorrect results.
• Amplified Risk in File Import Flows: Combined with the lack of JSON depth limits mentioned in the broader vulnerability description, a crafted import file could simultaneously trigger overflow and deeply nested parsing — compounding the resource exhaustion.

The Fix

What Changed

The fix is elegant and idiomatic Rust — replace the unchecked addition with checked_add, which returns None on overflow instead of wrapping:

Before (vulnerable):

self.bytes_received += n;

After (secure):

self.bytes_received = self.bytes_received
    .checked_add(n)
    .ok_or_else(|| FenvoyError::InvalidMessage("bytes_received overflow".into()))?;

How It Works

Rust's standard library provides checked arithmetic methods on all integer types:

checked_add returns an Option<T>:
- Some(result) if the addition succeeded without overflow
- None if overflow would have occurred

The .ok_or_else(...) call converts None into a meaningful error, and the ? operator propagates that error up the call stack — terminating the transfer cleanly with an informative error message instead of silently continuing with a corrupted counter.

Why This Fix Is the Right Approach

There are several ways to handle overflow, but checked_add with an error is the best choice here because:

1. It fails fast — the transfer is immediately terminated when something impossible happens.
2. It's explicit — future maintainers can see that overflow is a considered case, not an accident.
3. It's informative — the error message "bytes_received overflow" makes debugging and log analysis straightforward.
4. It doesn't mask bugs — unlike saturating_add (which would silently cap the value), an error forces the issue to be handled.

Conclusion

This vulnerability is a perfect case study in the gap between "memory safe" and "fully safe." Rust's ownership model prevents an entire class of bugs that plague C and C++ — but integer arithmetic in release mode is still a sharp edge that can cut you if you're not careful.

The key takeaways:

• 🦀 Rust release builds do NOT panic on integer overflow — silent wraparound is the default.
• 🔢 Use checked_add (and friends) for any security-sensitive arithmetic — especially byte counters, size tracking, and index calculations.
• 🚦 Validate continuously, not just at the start — an attacker controls the data stream, not just the initial handshake.
• 🧪 Test in release mode — your debug tests won't catch overflow bugs in production.
• 📏 Pair numeric safety with resource limits — overflow protection and size caps are complementary, not alternatives.

A single += replaced with checked_add closed this vulnerability. It's a small change with a big impact — and a great reminder that secure code is built from careful, deliberate choices at every level, even the arithmetic.

Write safe code. Check your math. Ship with confidence.

Found a vulnerability in your own codebase? Consider responsible disclosure and always patch promptly. Security is a team sport.