Critical Buffer Overflow Fix: How Unbounded strcpy() Puts Your System at Risk

Introduction

Buffer overflow vulnerabilities are among the oldest and most dangerous classes of bugs in systems programming — and they're still showing up in production code today. This post covers a critical-severity buffer overflow discovered in a custom strcpy() implementation inside src/lib/string.c, and walks through exactly how it was fixed.

If you write C code — especially in kernel, OS, or embedded contexts — this one is for you.

Why Should Developers Care?

Buffer overflows don't just crash programs. In the right context, they are the foundation of some of the most devastating exploits ever written: privilege escalation, remote code execution, kernel panics, and full system compromise. The C standard library's own strcpy() has been flagged as unsafe for decades, yet reimplementations of the same dangerous pattern keep appearing in codebases worldwide.

Understanding why this pattern is dangerous — and how to fix it — is fundamental knowledge for any developer working close to the metal.

The Vulnerability Explained

What Went Wrong

The vulnerable code lived at src/lib/string.c:121. Here's the original implementation:

// Copy a string from a source to a destination
char *strcpy(char *dest, const char *src) {
    int i = 0;
    while (src[i] != '\0') {
        dest[i] = src[i];
        i++;
    }
    dest[i] = 0;
    return(dest);
}

At first glance, this looks like a straightforward string copy. It iterates through src character by character and writes each byte into dest. The loop stops when it hits the null terminator '\0'.

The problem: There is absolutely no check on the size of dest.

The function blindly trusts that dest is large enough to hold whatever src contains. If src is longer than the allocated buffer for dest, the function will keep writing past the end of that buffer — overwriting whatever memory comes next.

How Could It Be Exploited?

The impact depends heavily on where dest lives in memory:

Stack overflow scenario:
If dest is a stack-allocated buffer, an attacker who controls the content of src can overwrite the function's saved return address. When the function returns, execution jumps to attacker-controlled memory — a classic stack smashing attack.

[  dest buffer  ][  saved frame pointer  ][  return address  ]
     ↑ write starts here, overflows into return address →→→→

Heap overflow scenario:
If dest is heap-allocated, writing past its boundary corrupts adjacent heap metadata or other heap objects. This can be leveraged to redirect execution, corrupt data structures, or cause a use-after-free condition.

Kernel context (most severe):
This code exists in what appears to be a kernel or OS library (src/lib/). In kernel space, there is no memory protection boundary between user and kernel. Corrupting a return address or a critical kernel data structure can cause:
- Kernel panic / system crash
- Privilege escalation (ring 0 code execution)
- Persistent rootkit installation
- Destruction of filesystem metadata

Real-World Attack Scenario

Imagine a kernel module that reads a filename from user input and calls this strcpy() to copy it into a fixed-size buffer:

char kernel_buf[64];
strcpy(kernel_buf, user_supplied_filename);  // ← DANGEROUS

An attacker supplies a filename of 200 characters. The function copies all 200 bytes, overflowing kernel_buf by 136 bytes. On a predictable kernel stack layout, those 136 bytes land squarely on top of the return address. The attacker has just achieved kernel-level code execution.

This is not theoretical. Vulnerabilities of this exact class have been assigned CVEs and exploited in production systems.

The Fix

What Changed

The fix replaces the unbounded strcpy() with a size-aware strlcpy() across two files:

src/lib/string.c — Core implementation:

// BEFORE (vulnerable)
char *strcpy(char *dest, const char *src) {
    int i = 0;
    while (src[i] != '\0') {
        dest[i] = src[i];
        i++;
    }
    dest[i] = 0;
    return(dest);
}

// AFTER (safe)
char *strlcpy(char *dest, const char *src, size_t size) {
    size_t i = 0;
    if (size == 0)
        return dest;
    while (i < size && src[i] != '\0') {
        dest[i] = src[i];
        i++;
    }
    dest[i] = '\0';
    return dest;
}

src/include/string.h — Header update:

// BEFORE
char *strcpy(char *dest, const char *src);

// AFTER
char *strlcpy(char *dest, const char *src, size_t size);

src/lib/memory.c — Call site updated:

// BEFORE
strcpy(cpy, src);

// AFTER
strlcpy(cpy, src, strlen(src) + 1);

How Does the Fix Solve the Problem?

The new strlcpy() function introduces three critical safety improvements:

1. Explicit size parameter: The caller is now required to pass the size of the destination buffer. There is no way to call this function without specifying the limit. This makes the safe behavior the only option.

2. Bounded loop: The while condition now checks i < size before writing. The loop will never write beyond the size boundary, regardless of how long src is.

c while (i < size && src[i] != '\0') { // ← size check added

1. Zero-size guard: The early return for size == 0 prevents an off-by-one write to dest[0] when the buffer has no space at all.

2. Correct index type: The loop variable was changed from int to size_t, which is the correct unsigned type for memory sizes and prevents signed/unsigned comparison warnings that can mask bugs.

The Semantics of strlcpy

It's worth noting that this implementation follows the spirit of the BSD strlcpy() convention: copy at most size - 1 characters and always null-terminate. The caller passes the total buffer size (including the null terminator), and the function guarantees the result is always a valid null-terminated string — even when truncation occurs.

Conclusion

A single missing bounds check in a string copy function is all it takes to open the door to some of the most severe exploits in systems security. This fix — replacing an unbounded strcpy() with a size-aware strlcpy() — is a small code change with enormous security implications, particularly in a kernel or OS context where there is no safety net between a memory corruption bug and full system compromise.

Key takeaways:

• ✅ Always use size-bounded string functions in C
• ✅ Make buffer size a required parameter in your APIs
• ✅ Run static analysis and sanitizers as part of your CI pipeline
• ✅ Pay extra attention to string handling in privileged code (kernel, daemons, setuid binaries)
• ✅ When you write a custom implementation of a standard function, hold it to the same safety standards — or higher

Buffer overflows are preventable. The tools, patterns, and knowledge to avoid them are widely available. The only thing standing between a vulnerable codebase and a secure one is the discipline to apply them consistently.

This vulnerability was automatically detected and fixed by OrbisAI Security. Automated security scanning helps catch dangerous patterns before they reach production.