Buffer Overflow via Unsafe sprintf() in C Game Menu: How Shared Campaign Files Could Lead to Code Execution

Introduction

String formatting functions are among the oldest tools in the C programmer's toolkit — and among the most dangerous when misused. A recently patched vulnerability in src/mainmenu.c is a textbook example of how a handful of unbounded sprintf() calls, scattered across a menu rendering system, can quietly open the door to arbitrary code execution.

What makes this finding particularly sobering is the attack vector: campaign files. These are ordinary data files that players share freely through forums, Discord servers, and game community websites. No special privileges, no network intrusion, no reverse engineering required. An attacker simply crafts a malicious campaign file, shares it with the community, and waits.

If you write C or C++, work on applications that parse user-supplied files, or maintain any codebase that processes untrusted string data, this vulnerability — and its fix — is directly relevant to you.

The Vulnerability Explained

What Is a Buffer Overflow?

A stack buffer overflow occurs when a program writes more data into a fixed-size memory buffer than that buffer was allocated to hold. In C, when a local variable (like a character array) is declared on the stack, it sits adjacent to other critical data — including the return address that tells the CPU where to go after a function finishes executing.

If an attacker can control what gets written into that buffer, and write enough of it, they can overwrite that return address with a value of their choosing. The next time the function returns, the CPU jumps to attacker-controlled code. This is the essence of arbitrary code execution via stack buffer overflow.

The Vulnerable Code

The root cause in mainmenu.c is the use of sprintf() — a C standard library function that formats and writes a string into a buffer — without any length constraint. Here are the four vulnerable call sites:

Site 1 — Campaign title display:

char buf[SOME_FIXED_SIZE];
// ...
sprintf(buf, "> %s", titleBuf);  // titleBuf is attacker-controlled

Site 2 — Campaign filename display:

char s[CDOGS_FILENAME_MAX];
sprintf(s, "( %s )", mData->Entry->Filename);  // Filename from campaign file

Site 3 — Folder name construction:

char folderName[CDOGS_FILENAME_MAX];
sprintf(folderName, "%s/", subList->Name);  // Name from campaign file

Site 4 — LAN server menu item:

sprintf(
    buf, "%s (%s:%u) - %s: %s (# %d), p: %d/%d %dms",
    si->ServerInfo.Hostname, ipbuf, si->Addr.port, ...
);  // Multiple attacker-influenced fields

In every case, the destination buffer has a fixed, compile-time size, but sprintf() will happily write as many bytes as the format string produces — with no regard for how much space is actually available.

The Attack Chain

Here's how an attacker exploits this in practice:

1. Craft a malicious campaign file containing an oversized string in a field like Filename, Name, or CampaignName — values that are read from disk and passed directly into these sprintf() calls.

2. Distribute the file through legitimate community channels (forums, mod repositories, Discord). The file looks like any other campaign.

3. Victim loads the campaign in the game's main menu. The menu code reads the oversized string and calls sprintf(), which writes past the end of the fixed-size stack buffer.

4. Stack corruption occurs. Depending on the overflow size and content, the attacker can overwrite the saved return address (or heap metadata in heap-based variants) with a pointer to shellcode or a ROP gadget chain.

5. Code execution. When the affected function returns, the CPU jumps to attacker-controlled code running with the same privileges as the game process.

Why This Is High Risk

Several factors elevate this beyond a theoretical concern:

• No authentication required. Campaign files are public, shareable data. Any community member can be targeted.
• Multiple overflow sites. Four separate sprintf() calls are affected, increasing the likelihood that at least one is exploitable on a given platform or build configuration.
• Combined with strcpy() in hiscores.c. The PR notes that this vulnerability is part of a broader attack chain involving unbounded strcpy() calls elsewhere in the codebase, making exploitation more flexible.
• Stack overflows are well-understood. Decades of exploit development tooling and techniques exist for precisely this class of vulnerability.

The Fix

The fix is elegantly simple: replace every sprintf() call with snprintf(), passing the size of the destination buffer as the second argument.

Before and After

Site 1:

// BEFORE — unbounded write into buf
sprintf(buf, "> %s", titleBuf);

// AFTER — write at most sizeof(buf) bytes, including null terminator
snprintf(buf, sizeof buf, "> %s", titleBuf);

Site 2:

// BEFORE
sprintf(s, "( %s )", mData->Entry->Filename);

// AFTER
snprintf(s, sizeof s, "( %s )", mData->Entry->Filename);

Site 3:

// BEFORE
sprintf(folderName, "%s/", subList->Name);

// AFTER
snprintf(folderName, sizeof folderName, "%s/", subList->Name);

Site 4:

// BEFORE
sprintf(
    buf, "%s (%s:%u) - %s: %s (# %d), p: %d/%d %dms",
    si->ServerInfo.Hostname, ipbuf, ...
);

// AFTER
snprintf(
    buf, sizeof buf, "%s (%s:%u) - %s: %s (# %d), p: %d/%d %dms",
    si->ServerInfo.Hostname, ipbuf, ...
);

How snprintf() Solves the Problem

snprintf(dest, n, fmt, ...) guarantees that at most n - 1 characters are written to dest, always null-terminating the result (when n > 0). No matter how long the attacker-controlled input string is, the write is bounded by the actual size of the buffer.

The use of sizeof buf (rather than a hardcoded constant) is important: it ties the size argument directly to the buffer declaration, so if the buffer size ever changes during refactoring, the snprintf() limit automatically stays in sync.

Note on truncation: snprintf() prevents the overflow but may silently truncate the output string. For display strings in a game menu, truncation is acceptable — the menu item shows a shorter name rather than crashing or executing attacker code. In contexts where truncation would cause logical errors (e.g., a file path), additional validation is needed after the call.

Conclusion

This vulnerability is a reminder that the most dangerous bugs are often the most familiar ones. sprintf() has been in the C standard library since 1978. Developers use it every day without incident — until the day untrusted input reaches it without length validation.

The four-line fix — swapping sprintf() for snprintf() with a proper size argument — closes an attack chain that could have allowed arbitrary code execution on any player who loaded a malicious campaign file. The effort to fix it was minimal. The potential impact of leaving it unfixed was not.

Key takeaways:

• Never use sprintf(), strcpy(), or other unbounded string functions on data that originates outside your program.
• Validate and bound-check untrusted input at ingestion time, not just at use time.
• Use snprintf() with sizeof(buffer) — not a hardcoded constant — to stay safe through refactoring.
• Layer compiler protections (-fstack-protector-strong, FORTIFY_SOURCE) and static analysis into your build pipeline.
• In games and applications with community file sharing, campaign files, save files, and mod archives are attacker-controlled input. Treat them accordingly.

Secure coding isn't about paranoia — it's about building the habit of asking, "What happens if this string is 10,000 characters long?" before you ship.