bug-ncurses
[Top][All Lists]
Advanced

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

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


From: Thomas Dickey
Subject: Re: A heap-buffer-overflow in captoinfo.c:321:12
Date: Tue, 4 Aug 2020 20:14:20 -0400
User-agent: NeoMutt/20170113 (1.7.2)

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
> attachment.
> 
> ## 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.

> v6_2_20200801)
> 
> ## Configure
> 
> CFLAGS="-g -fsanitize=address" LDFLAGS="-fsanitize=address" ./configure
> --enable-static

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== 
==4909== Searching for pointers to 1 not-freed blocks
==4909== Checked 68,824 bytes
==4909== 
==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== 
==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>
https://invisible-island.net
ftp://ftp.invisible-island.net

Attachment: signature.asc
Description: PGP signature


reply via email to

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