On October 31, 2022, a new vulnerability was reported in timg, specifically affecting version 1.4.4. Identified as CVE-2022-43151, this issue is a memory leak found in the function timg::QueryBackgroundColor() at /timg/src/term-query.cc. In this long read, we will explore how this vulnerability occurs, how it can be triggered, and what implications it holds. No prior expertise in memory management is assumed—just basic C++ understanding.
What is timg?
timg is a cross-platform command-line image viewer that can display images directly in your terminal using 24bit ANSI escape sequences.
It is used heavily by *nix users for quick image previews.
About the Vulnerability
CVE-2022-43151 is a memory leak, meaning the program allocates heap memory but doesn't free it, causing the process to use more and more memory over time. This can lead to a Denial of Service (DoS) if memory usage grows uncontrolled.
Where is the Issue?
The flaw exists in the timg::QueryBackgroundColor() function.
This function is responsible for querying the terminal's background color. The bug happens because the function allocates memory but never frees it.
Here is a simplified snippet based on /timg/src/term-query.cc
// Vulnerable function in timg/src/term-query.cc
std::string QueryBackgroundColor() {
char *backgroundColor = (char *)malloc(32); // Allocates memory
// ... Code that fills backgroundColor ...
std::string ret = std::string(backgroundColor);
// Oops! backgroundColor is never freed!
return ret;
}
Problem:
The backgroundColor pointer is allocated with malloc, and its contents are copied into a std::string.
But there is no free(backgroundColor); call! This means each call to QueryBackgroundColor() will leak 32 bytes.
Exploitation Scenario
An attacker cannot directly exploit this over the network, but any user or script that calls timg repeatedly, especially inside a loop, can exhaust system memory over time.
Consider this bash loop
while true; do
timg someimage.png
done
Each iteration, depending on how timg uses QueryBackgroundColor(), leaks 32 bytes. It may not seem much, but over hours, this adds up, and the process may eventually crash or be killed by the OS.
Suppose you write a C++ program that uses the library behind timg
#include "timg/term-query.h"
int main() {
for (int i = ; i < 100000; ++i) {
std::string bg = timg::QueryBackgroundColor();
}
return ;
}
The right fix is to free the buffer
std::string QueryBackgroundColor() {
char *backgroundColor = (char *)malloc(32);
// ...use backgroundColor...
std::string ret = std::string(backgroundColor);
free(backgroundColor); // FIX: free memory!
return ret;
}
Or, better yet, avoid manual memory management and use std::vector or std::array.
Denial of Service: If timg is called in a loop, it can consume all memory
- Resource Wastage: Systems running timg as part of scripts or background jobs may slowly exhaust memory
References
- CVE Entry (NVD)
- Original GitHub Issue
- Commit fixing the issue
- timg official repository
Conclusion
CVE-2022-43151 is a simple but classic C++ mistake—forgetting to free heap memory. Although the bug won't immediately allow code execution, it can be abused for Denial of Service or simply cause timg to crash after prolonged use. Always make sure to review memory allocations and prefer RAII principles in C++ to avoid these issues.
If you're packaging or deploying timg, make sure version 1.4.4 is either patched or upgraded to a fixed version.
Summary Table
| Aspect | Detail |
|--------|---------------------------------------------|
| CVE | CVE-2022-43151 |
| Affected | timg v1.4.4 |
| Location | /timg/src/term-query.cc |
| Function | timg::QueryBackgroundColor() |
| Type | Memory Leak |
| Exploitable | Yes (DoS by memory exhaustion) |
| Remediation | Free allocated memory after use |
Timeline
Published on: 10/31/2022 19:15:00 UTC
Last modified on: 11/02/2022 00:16:00 UTC