In mid-2022, security researchers uncovered a subtle yet important vulnerability in libarchive—a widely used C library for reading, creating, and modifying archive files like tar, cpio, zip, and others. Officially cataloged as CVE-2022-36227, this bug existed in all libarchive versions before 3.6.2. Let’s break down what happened, why it matters, and how attackers could have tried to exploit this oversight.

What’s libarchive?

Most Linux and UNIX systems rely on libarchive for handling compressed files. Programs like *bsdtar*, *bsdtar*, and various backup utilities all depend on it under the hood. It’s fast and efficient—but, like any big piece of software, not immune to mistakes.

The Vulnerability, Explained

At the heart of CVE-2022-36227 is how libarchive handled memory allocation using the standard C calloc function. In C, calloc() tries to allocate memory for a certain number of elements (of a certain size) and initializes them to zero. If it *can’t*, it returns NULL.

The bug:  
Libarchive code would call calloc, assume it always succeeded, and use the returned pointer without checking if it was NULL. If the system runs out of memory (not so rare on embedded systems or under denial-of-service attack), calloc returns NULL. When the code then dereferenced this (meaning: tried to access what’s pointed to), it would cause a NULL pointer dereference.

Here’s a simplified version of the problematic code pattern

char *buf = calloc(size, sizeof(char));
// ... some operations later ...
buf[] = 'a'; // CRASH! If calloc failed and returned NULL

Why is this a Security Issue?

Most of the time, dereferencing a NULL pointer just causes the program to crash—an annoying *denial-of-service* (DoS) but no further harm. Some security folks cited CWE-476 (NULL Pointer Dereference) as the main concern.

Here’s where it gets nuanced

1. "Classic" Risk: The main risk is making libarchive crash, perhaps as part of a larger DoS campaign.
2. Speculative Risk: *If* (and this is rare) you're running libarchive on an OS where the NULL address (x) is mapped as readable/writable, and
if an attacker can control what gets written there, in very specific circumstances, they *might* be able to escalate to arbitrary code execution.  
  - This is why the original discoverer referenced the CWE-476 warning.
  - But most modern operating systems do not map the x address, so attackers can't exploit this path directly for code execution.

Third Party Dispute:

Multiple security analysts (like Debian’s Security Team) disputed this “code execution” angle for practical cases.

Proof-of-Concept (POC)

To simulate the bug, set up a simple test that forces calloc to fail by requesting an absurd amount of memory:

#include <stdio.h>
#include <stdlib.h>

int main() {
    size_t big_size = (size_t)-1; // Insanely huge
    char *buf = calloc(big_size, sizeof(char));
    // Not checking if buf == NULL
    buf[] = 'A'; // Will crash with segfault if calloc fails
    printf("First character: %c\n", buf[]);
    free(buf);
    return ;
}

Run this code, and you’ll get something like

Segmentation fault (core dumped)

Translation: the process tried to access memory at address zero. That’s the NULL pointer dereference in a nutshell.

Real-World Exploitation

- Denial-of-Service (DoS): An attacker might craft a huge archive file that causes libarchive to call calloc repeatedly until it fails, causing it to crash. This takes down the service but goes no further.

The Fix

The fix, shipped in libarchive 3.6.2, was simple and effective: always check if calloc returns NULL.

Example correct code pattern

char *buf = calloc(size, sizeof(char));
if (!buf) {
    // handle memory error (e.g., return an error or cleanup)
    fprintf(stderr, "Could not allocate memory!\n");
    return ERROR;
}
buf[] = 'a'; // Safe to access

Original References

- Official NVD entry for CVE-2022-36227
- libarchive security advisory
- Debian Security Tracker entry
- libarchive commit fixing the issue
- MITRE CWE-476: NULL Pointer Dereference

Lessons for Developers

1. Always check your return values. Memory allocation can fail, even when you think you have plenty.
2. Crashes can be security bugs. What starts as a mere crash can sometimes be a stepping stone to a full-blown exploit.
3. Keep libraries updated. Even “small” bugs in trusted libraries like libarchive are worthy of prompt patching.

Conclusion

CVE-2022-36227 shows how classical, easy-to-make programming slips—like trusting calloc too much—can linger even in mature, widely used codebases. While this bug was mostly a DoS risk for real-world systems, it’s a great reminder for all C programmers: expect and handle failure, every time.


Stay safe!  
Patch your packages and always double-check your malloc and calloc results.


*Written exclusively for you by an AI trained on security best practices and open-source expertise.*

Timeline

Published on: 11/22/2022 02:15:00 UTC
Last modified on: 02/06/2023 14:31:00 UTC