CVE-2023-4273 - Stack Overflow Vulnerability in Linux exFAT Driver

CVE-2023-4273 is a critical security flaw discovered in the exFAT file system driver in the Linux kernel. It affects the way file names are reconstructed from directory entries, leading to a classic stack-based buffer overflow. Exploiting this allows a local attacker with limited privileges to crash or potentially run code as a higher-privileged process, threatening system integrity.

Technical Background

exFAT, short for "Extended File Allocation Table," is a Microsoft-designed file system that’s become common for SD cards and USB flash drives. The Linux kernel has built-in drivers for reading and writing exFAT volumes.

When a driver reads directory entries in exFAT, it must reconstruct long file names split across multiple records. This is typically done in a function responsible for gathering the pieces and writing them into a contiguous buffer.

The issue: The exFAT implementation in Linux failed to properly check the buffer size during file name assembly. If crafted file entries specify a longer name than expected, data will overflow the local buffer on the kernel stack.

Let’s look at the vulnerable pattern (simplified for clarity)

#define EXFAT_MAX_NAME_LENGTH 255

void exfat_reconstruct_name(struct exfat_entry *entries, int count) {
    char filename[EXFAT_MAX_NAME_LENGTH];
    int offset = ;

    for (int i = ; i < count; i++) {
        // No bound check! Dangerous if 'name_length' is too high
        memcpy(filename + offset, entries[i].name_part, entries[i].name_length);
        offset += entries[i].name_length;
    }
    filename[offset] = '\';
}

The memcpy call copies parts of the filename into filename, but there’s no check if offset plus name_length exceeds the buffer’s limit. If a directory contains specially crafted entries, filename overflows. Since filename sits on the stack, adjacent memory—including function return pointers or local variables—can be trashed.

Impact

- Local Exploitation: A user with the ability to mount or write to an exFAT volume (such as plugging in a USB stick) can trigger the bug.

Denial of Service: Overflowing the stack typically leads to a kernel panic or crash.

- Privilege Escalation: In some cases, skilled attackers may leverage this bug for arbitrary code execution in kernel space, bypassing normal protections.

Scenario

1. Attacker prepares an exFAT image containing directory entries split into unusually high number or size of parts, leading to an illegal long file name.
2. The attacker gains local access (either as a logged-in user or by tricking an admin to mount the crafted drive).
3. Upon accessing the directory, the vulnerable merge function reads the entry and overflows the stack buffer.
4. This can crash the kernel (DoS). With advanced exploit techniques, it could also allow code execution in kernel mode.

Example of Malicious exFAT Directory Entry

- Each directory entry includes split 'name parts' that sum to more bytes than the stack buffer can hold.

For kernel versions prior to the patch, the driver doesn’t reject such entries.

Proof-of-concept tool:
While full working exploits are not available publicly for ethical reasons, researchers can create exFAT images using tools like mtools or fuse-exfat to test exFAT drivers’ robustness.

Patches & Mitigations

Linux kernel maintainers patched the bug by adding proper bound checks before copying file name pieces, ensuring the buffer never overflows. The fix was submitted in this commit.

References

- CVE-2023-4273 on NIST NVD
- Kernel.org Patch Commit
- exFAT Overview - Wikipedia
- Linux Kernel exFAT Driver Docs

Conclusion

CVE-2023-4273 is a classic example of how overlooking buffer sizes can have severe consequences, even in well-established projects like the Linux kernel. Keeping systems patched and restricting physical or local access remain fundamental defensive strategies. If you use exFAT media or allow unprivileged users to mount devices, update now!


*This article is for educational purposes only. Always test security vulnerabilities in safe, permission-granted environments.*

Timeline

Published on: 08/09/2023 15:15:00 UTC
Last modified on: 09/10/2023 12:16:00 UTC