In early 2024, a security vulnerability tracked as CVE-2023-52464 was discovered and resolved in the Linux kernel. This bug affected the ThunderX EDAC (Error Detection and Correction) driver, putting certain server deployments at risk of buffer overflow exploits. The culprit? A common misunderstanding about how the C standard function strncat() works, risking out-of-bounds string access—an error that can lead to crashes or even malicious exploitation.

Let's unpack the technical details, see how the bug looks in code, and explain how it has been resolved.

What's the problem?

In the file drivers/edac/thunderx_edac.c, the function thunderx_ocx_com_threaded_isr uses strncat() in an unsafe way:

The destination buffer msg is allocated with a fixed size (OCX_MESSAGE_SIZE, 1024 bytes).

- strncat(msg, other, OCX_MESSAGE_SIZE) is used to concatenate a string, with OCX_MESSAGE_SIZE as the n parameter.

The bug:
strncat() does not behave like strlcat(). The third parameter to strncat() defines how many bytes to append from the source string, not the total size of the destination buffer. If the buffer already contains data and you try to append up to its length, you can overflow it.

What should have happened?

The code author expected strncat() to prevent buffer overflows by using the total buffer size as the limit—like strlcat() does. In reality, this opens the door to writing past the end of the buffer, leading to undefined behavior or a crash.

Vulnerable Code Example

Here’s a simplified, *exclusive* look at the faulty logic.

#define OCX_MESSAGE_SIZE 1024

void thunderx_ocx_com_threaded_isr() {
    char msg[OCX_MESSAGE_SIZE];
    const char *other = "Error detected!";

    // BAD: This can write past the end of 'msg'
    strncat(msg, other, OCX_MESSAGE_SIZE);

    // ... further processing and usage of msg ...
}

Imagine if msg already had some data from a previous operation. By telling strncat() to copy up to 1024 bytes *without* checking how much space is left, you can easily write beyond the end of msg, causing a buffer overflow.

How dangerous is it?

This bug could allow an attacker—or a corrupted device—to trigger a memory write outside the allocated buffer. That may rarely cause major issues in this userland-less kernel code, but:

Denial of service: A crash or kernel panic could be induced on vulnerable hardware.

- Hard to exploit: Because it lives inside a hardware error handler, exploiting it reliably would be tricky, but not impossible for targeted attacks.

Proof of Concept (PoC) Scenario

Suppose an attacker manages to influence the contents of other and call the handler repeatedly, eventually overflowing msg and corrupting adjacent kernel structures.

Note: No easy in-the-wild exploit is published as of June 2024.

Fixed Implementation

The Linux maintainers fixed this by switching to strlcat(), which properly limits the amount of text copied into msg based on the total buffer size.

Patched code

#include <string.h> // for strlcat

#define OCX_MESSAGE_SIZE 1024

void thunderx_ocx_com_threaded_isr() {
    char msg[OCX_MESSAGE_SIZE];
    const char *other = "Error detected!";

    // GOOD: strlcat prevents buffer overflow
    strlcat(msg, other, OCX_MESSAGE_SIZE);

    // ... further processing and usage of msg ...
}

Here, even if msg is partially filled, strlcat() ensures that the total content *never* exceeds the buffer size, preventing out-of-bounds access.

References

- Upstream commit on kernel.org
- CVE record for CVE-2023-52464 at Mitre
- Linux kernel EDAC ThunderX driver source
- string(3) man page (strncat vs strlcat)

Conclusion

CVE-2023-52464 highlights a classic pitfall in C programming: misunderstanding string manipulation APIs can introduce subtle but critical bugs. Always ensure that buffer sizes and string functions align, and when in doubt, prefer safer alternatives like strlcat() (if available) to avoid out-of-bounds risks!

> Advice: Keep your Linux kernel up to date, especially if you run ThunderX-based servers or use the edac subsystem for RAS (Reliability, Availability, and Serviceability).


*This post is exclusive and written in simple, straightforward language for engineers, researchers, and sysadmins concerned about Linux kernel security.*

Timeline

Published on: 02/23/2024 15:15:08 UTC
Last modified on: 04/17/2024 20:03:39 UTC