How can integer type mismatches lead to security vulnerabilities?

A signed/unsigned mix-up can let a length check pass for a negative value, which then becomes a huge size — a classic memory-safety bug.

* A negative signed length passes a greater-than check unchanged and then becomes a huge unsigned value inside memcpy, triggering a memory-leaking over-read. *

// Kernel code with vulnerability:
int copy_from_kernel(void *user_dest, int maxlen) {
    int len = maxlen > KSIZE ? KSIZE : maxlen;
    memcpy(user_dest, kbuf, len);
    return len;
}

The bug:

• maxlen is signed int
• Comparison maxlen > KSIZE works for positive values
• If attacker passes negative maxlen, check passes!
• memcpy interprets negative as huge positive (unsigned)
• Result: Reads arbitrary kernel memory!

Real-world impact: This was similar to FreeBSD's getpeername vulnerability - leaked kernel secrets like credit card numbers.

Go deeper:

• CWE-195: Signed to Unsigned Conversion Error (MITRE) — a negative signed length cast to size_t becomes huge, breaking memcpy/malloc bounds.
• CWE-190: Integer Overflow or Wraparound (MITRE) — overflowed size calculations under-allocate buffers, a top-25 weakness.