CVE-2025-25724 - Buffer Overflow and DoS in libarchive’s list_item_verbose Function

Libarchive is a widely used C library for reading and writing different streaming archive formats, including tar, cpio, and zip. If you’re building tools that work with TAR files (like tar itself), there’s a high chance you rely on libarchive. Recently, a new security vulnerability, CVE-2025-25724, has been disclosed in libarchive up to version 3.7.7.

This post explains, in simple terms, what this vulnerability is, how it works, and why you (or your sysadmin) should care. I’ll also give you live code snippets that highlight the issue, and links to official references.

What is CVE-2025-25724 About?

In libarchive, specifically in the file tar/util.c, there’s a function named list_item_verbose. When you extract or list files in a TAR archive (with verbose mode level 2), this function formats time info (like last modified date) for display.

The bug? list_item_verbose allocates a 100-byte buffer to store the formatted date and time, then uses strftime() to fill that buffer, *but it doesn’t check how much was written*. Under certain circumstances, especially with custom locales where date representations are longer, strftime can overflow the buffer.

Denial of Service (DoS): Crashing the tool by smashing the stack.

- Other impact: In theory, a sophisticated exploit could be possible, but so far, only DoS has been demonstrated.

This vulnerability can be triggered by a specially-crafted TAR archive, read with verbose flag set to 2.

Here’s a simplified version (from tar/util.c) showing where the trouble is

char timebuff[100];
strftime(timebuff, sizeof(timebuff), "%c", localtime(&sb->st_mtime));
fprintf(out, "%s ", timebuff);

What’s the problem? The return value of strftime() is not checked. If the formatted string is too big for timebuff, strftime will return , but the buffer is not null-terminated, and printing it with %s causes undefined behavior — typically reading past buffer, leaking memory contents, or crashing the program.

Create a tarball with a file showing a specific timestamp.

2. Set a custom locale on the target system, where strftime("%c", ...) outputs >100 bytes for that timestamp.
3. List the tar contents with verbose level 2 (e.g., bsdtar -vvf archive.tar or tar -vvf archive.tar)

In practice: Attackers can construct TARs and ask users to list them, leveraging exotic locales.

Here’s some C code to simulate the vulnerability (slightly simplified for demo purposes)

#include <time.h>
#include <stdio.h>
#include <locale.h>

int main(void) {
    // Set locale to a language with long date formats.
    setlocale(LC_TIME, "de_DE.UTF-8"); // Use a verbose locale if available

    // Create a time struct with arbitrary time
    time_t altered_time = time(NULL);
    char buffer[100];  // Vulnerable buffer

    // This will likely overflow buffer if the date is too long for the locale
    strftime(buffer, sizeof(buffer), "%A, %d. %B %Y, %H:%M:%S %Z", localtime(&altered_time));
    printf("Formatted date: %s\n", buffer);
    return ;
}

Run this and try to set a locale where the date string is especially long. The result: buffer may not contain a null-terminated string, leading to possible overflow.

For an actual exploit: An attacker would bundle crafted file timestamps in the archive and specify/trigger a target locale.

Attack vector: Malicious tar archive, local or remote

- Mode of attack: Requires target to run archive with verbose flag (prevalent for admins/users checking large archives)

It’s always best to consult primary sources

- CVE Record on MITRE (pending link)
- libarchive issue tracker: GitHub Issue #2057
- libarchive 3.7.8 release notes
- NVD entry (pending publication)

Patch libarchive: Upgrade to 3.7.8 or newer as soon as it’s out.

- Mitigate in the meantime: Avoid running tar or related tools with -vv on untrusted archives, especially in exotic locales.
- Continued Security: Always sanitize and validate archives before processing them in batch or automated jobs.

Conclusion

CVE-2025-25724 in libarchive reminds us: even basic errors (like missing a return value check) in trusted C code can bite. If you maintain systems, update libarchive. If you write backup software or process TARs, double-check your dependencies.

Stay safe — and if you find any archives out in the wild, don’t list them with verbose flags unless you trust the sender *and* your underlying libraries!


*This writeup is exclusive and aims to clarify CVE-2025-25724 for sysadmins, developers, and security researchers alike. Feel free to share any findings or insights in the comments.*

Timeline

Published on: 03/02/2025 02:15:36 UTC