[<prev] [next>] [day] [month] [year] [list]
Message-ID: <875x9tiy64.fsf@gmail.com>
Date: Thu, 25 Dec 2025 21:56:19 -0800
From: Collin Funk <collin.funk1@...il.com>
To: oss-security@...ts.openwall.com
Subject: CVE-2018-25153 against GNU barcode seems bogus
The description of CVE-2018-25153 states [1]:
GNU Barcode 0.99 contains a memory leak vulnerability in the command
line processing function within cmdline.c. Attackers can exploit
this vulnerability by providing specially crafted input that causes
unfreed memory allocations, potentially leading to denial of service
conditions.
It links to a page with the following description and "reproduction"
steps [2]:
# Desc: GNU Barcode suffers from a memory leak vulnerability, which can be exploited
# by malicious people to cause a DoS (Denial of Service). The vulnerability is
# caused due to an error in the 'cmdline.c', which can be exploited to cause a
# memory leak via a specially crafted file. The vulnerability is confirmed in
# version 0.99. Other versions may also be affected.
cmdline.c:
128: int commandline(struct commandline *args, int argc, char **argv,
129: char *errorhead)
130: {
131: struct commandline *ptr;
132: char *getopt_desc = (char *)calloc(512, 1);
133: int desc_offset = 0;
134: int opt, retval;
135: char *value;
lqwrm@...algear:~/research/barcode-0.99$ ./barcode -b id:000034,sig:06,src:000000,op:havoc,rep:128
[...]
==2183==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 512 byte(s) in 1 object(s) allocated from:
#0 0x7fcb3aca179a in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x9879a)
#1 0x407be2 in commandline /home/lqwrm/research/barcode-0.99/cmdline.c:132
Direct leak of 55 byte(s) in 1 object(s) allocated from:
#0 0x7fcb3aca1602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
#1 0x7fcb3a8ca489 in __strdup (/lib/x86_64-linux-gnu/libc.so.6+0x8b489)
SUMMARY: AddressSanitizer: 567 byte(s) leaked in 2 allocation(s).
I have never looked at GNU barcode previously. It took me a minute to
see that the referenced function "commandline" is called only once per
program invocation in main.c:
$ find . -name '*.[ch]' | xargs grep 'commandline[[:space:]]*('
./cmdline.c:int commandline(struct commandline *args, int argc, char **argv,
./cmdline.h:extern int commandline(struct commandline *args,
./main.c: retval = commandline(option_table, argc, argv, "Use: %s [options]\n");
Upon opening main.c you can see it is not in a loop and called directly
in the main function. It will never allocate and leak more than 512 bytes.
The strdup, which is not even mentioned in the "vulnerability"
description, can easily allocate more memory. It is called for every
'-b' option:
$ yes -- '-b id:000034,sig:06,src:000000,op:havoc,rep:128' \
| head -n 512 | tr '\n' ' ' | valgrind barcode 2>&1 > /dev/null \
| grep -F 'definitely lost'
==28596== definitely lost: 25,282 bytes in 195 blocks
Even then you would hit command-line argument limits before you allocate
enough memory to cause problems.
I hope VulnCheck does not find out about the rest of GNU's software,
which often does not call free before exiting.
Collin
[1] https://nvd.nist.gov/vuln/detail/CVE-2018-25153
[2] https://www.exploit-db.com/exploits/44798
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
