On Tue, May 15, 2018 at 08:01:19PM -0400, Thomas Dickey wrote: > On Tue, May 15, 2018 at 08:47:38PM +0200, Sven Joachim wrote: > > CC'ing ncurses maintainer, it looks like the library might be at fault > > here. > ... > > So it seems that the ncurses library did not allocate enough memory to > > hold all the color pairs in sp->_color_pairs, resulting in the eventual > > heap buffer overflow. > > > > That's how far I have tracked the issue, hopefully Thomas Dickey can > > investigate it further and even provide a fix. > > I can reproduce this, will see...
The problem is that f-irc asks for pair-content of pairs which it did not
initialize, and in doing this, found a case I'd overlooked in the logic
for dynamically allocating the color-pair table last year.
Here's the diff to fix ncurses:
--- ncurses/base/lib_color.c 2018/03/01 15:02:12 1.137
+++ ncurses/base/lib_color.c 2018/05/16 08:24:08
@@ -938,9 +938,12 @@
if (!ValidPair(sp, pair)) {
result = ERR;
} else {
- int fg = FORE_OF(sp->_color_pairs[pair]);
- int bg = BACK_OF(sp->_color_pairs[pair]);
+ int fg;
+ int bg;
+ _nc_reserve_pairs(sp, pair);
+ fg = FORE_OF(sp->_color_pairs[pair]);
+ bg = BACK_OF(sp->_color_pairs[pair]);
#if NCURSES_EXT_FUNCS
if (isDefaultColor(fg))
fg = -1;
f-irc, by the way, hits that function about a hundred times more than
the worst-case (7.2 million versus 65 thousand). The usual application
won't do anything like that...
--
Thomas E. Dickey <dic...@invisible-island.net>
https://invisible-island.net
ftp://ftp.invisible-island.net
signature.asc
Description: Digital signature
