[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A heap-buffer-overflow in captoinfo.c:321:12

From: Anshunkang Zhou
Subject: Re: A heap-buffer-overflow in captoinfo.c:321:12
Date: Wed, 5 Aug 2020 09:14:25 +0800

Dear developers,
    I am so sorry for the incorrect information, this bug was found in the 6.2-1 version of ncurses. And I think this bug has been fixed in recent commits.
    Actually I am using clang-6.0 to compile ncurses, the gcc 5.5 is just the system default compiler. I am trying to statically linking the executable, maybe I am adding the wrong options, but the default behavior is static linking.
    Thanks for your reply, and I will double check it next time. Sorry for the inconvenience.
On 08/5/2020 08:14Thomas Dickey<dickey@his.com> wrote:
On Tue, Aug 04, 2020 at 09:26:04PM +0800, Anshunkang Zhou wrote:
Dear Developers,
I found a heap-buffer-overflow in captoinfo.c:321:12, detailed system
information and build configuration is as follows, the poc is in the mail

## System info

Ubuntu X64, gcc (Ubuntu 5.5.0-12ubuntu1), ncurses (latest master label

What's the "5.5"?

gcc 5.5 is rather old.


## Configure

CFLAGS="-g -fsanitize=address" LDFLAGS="-fsanitize=address" ./configure

ncurses doesn't have an option "--enable-static".

By default, it configures static libraries.  For your purposes, this would
be the way to configure it:

CFLAGS="-g -fsanitize=address" \
LDFLAGS="-fsanitize=address" \
./configure --without-debug --without-ada

however, normally ncurses does not free memory (among other reasons,
performance, compatibilty, etc), and memory-leak checking is a
configure option:

CFLAGS="-g -fsanitize=address" \
LDFLAGS="-fsanitize=address" \
./configure --without-debug --without-ada --disable-leaks

I tried both with Debian 9's gcc 6.3.0, and AddressSanitizer reported
no errors. The memory leaks are something to investigate (but as noted
the other day, most of its messages are incorrect).

For comparison, doing this

./configure --without-debug --without-ada --with-valgrind

and using valgrind, it reports something different:

==4909== HEAP SUMMARY:
==4909==     in use at exit: 9 bytes in 1 blocks
==4909==   total heap usage: 24 allocs, 23 frees, 37,433 bytes allocated
==4909== Searching for pointers to 1 not-freed blocks
==4909== Checked 68,824 bytes
==4909== 9 bytes in 1 blocks are still reachable in loss record 1 of 1
==4909==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==4909==    by 0x50BC3B9: strdup (strdup.c:42)
==4909==    by 0x13029A: _nc_set_writedir (write_entry.c:251)
==4909==    by 0x113C3E: main (tic.c:1009)
==4909== LEAK SUMMARY:
==4909==    definitely lost: 0 bytes in 0 blocks
==4909==    indirectly lost: 0 bytes in 0 blocks
==4909==      possibly lost: 0 bytes in 0 blocks
==4909==    still reachable: 9 bytes in 1 blocks
==4909==         suppressed: 0 bytes in 0 blocks

(I've found valgrind's analysis and messages to be more reliable).

Thomas E. Dickey <dickey@invisible-island.net>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]