Re: lib/54085: curses crash with non-ascii on bottom line

[mlelstv%serpens.de@localhost (Michael van Elst)]

The following reply was made to PR lib/54085; it has been noted by GNATS.

From: mlelstv%serpens.de@localhost (Michael van Elst)
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: lib/54085: curses crash with non-ascii on bottom line
Date: Thu, 28 Mar 2019 06:50:56 -0000 (UTC)

 dholland%eecs.harvard.edu@localhost writes:
 
 >Thread 2 received signal SIGSEGV, Segmentation fault.
 >0x00007d0062c1adbd in ?? () from /usr/lib/libcurses.so.7
 >(gdb) where
 >#0  0x00007d0062c1adbd in ?? () from /usr/lib/libcurses.so.7
 >#1  0x00007d0062c1c63e in doupdate () from /usr/lib/libcurses.so.7
 >#2  0x00007d0062c1de6d in wrefresh () from /usr/lib/libcurses.so.7
 >#3  0x0000000000400ccb in main () at curse.c:13
 >(gdb) x/i 0x00007d0062c1adbd
 >=> 0x7d0062c1adbd:      mov    (%rdx),%ecx
 >(gdb) 
 
 The crash happens when accessing
 
 win->alines[H-1]->line[W]
 
 and
 
 scr->alines[H-1]->line[W]
 
 respectively. Both use an out of range column index and reach
 a guard area with the 0xa5 pattern.
 
 This is caused by code in makech(). It maintains two pointers
 nsp and csp that correspond to the line data at column wx.
 wx is checked against the line width to avoid dereferencing
 invalid pointers,  but in lines 1350ff the pointers are
 incremented (by 1) while the index is incremented by chw
 which, for wide chars, is the result of a wcwidth() call
 that may result in 0 or -1 for invalid byte sequences.
 
 -- 
 -- 
                                 Michael van Elst
 Internet: mlelstv%serpens.de@localhost
                                 "A potential Snark may lurk in every tree."