On 2018-05-16 04:34 -0400, Thomas Dickey wrote:
> 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;
Thanks, that helps. :-)
> f-irc, by the way, hits that function about a hundred times more than
> the worst-case (7.2 million versus 65 thousand).
Yes, the double loop in init_nick_colorpairs() is horribly inefficient.
Try to start f-irc with TERM=xterm-direct, I killed it after two
minutes of using 100% CPU.
> The usual application won't do anything like that...
There's a reason why nobody had noticed the problem earlier, I guess.
Cheers,
Sven
