bug-ncurses
[Top][All Lists]
Advanced

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

Re: Issue with unget_wch_sp and -D_FORTIFY_SOURCE


From: Thomas Dickey
Subject: Re: Issue with unget_wch_sp and -D_FORTIFY_SOURCE
Date: Wed, 6 Apr 2022 20:53:53 -0400
User-agent: Mutt/1.10.1 (2018-07-13)

On Wed, Apr 06, 2022 at 10:16:43AM +0200, Martin Liška wrote:
> Hi.
> 
> The original bug was seen in Python and reported here:
> https://bugs.python.org/issue47188
> 
> The root cause is that:
> 
> #8  0x00007ffff7a18b31 in wcrtomb (__ps=<optimized out>, __wchar=<optimized 
> out>, __s=<optimized out>, __s=<optimized out>, __wchar=<optimized out>, 
> __ps=<optimized out>) at /usr/include/bits/wchar2.h:402
> #9  unget_wch_sp (sp=0xab0920, wch=97 L'a') at 
> ../ncurses/./widechar/lib_unget_wch.c:89
> #10 0x00007ffff7a18b61 in unget_wch (wch=<optimized out>) at 
> ../ncurses/./widechar/lib_unget_wch.c:113
> 
> wcrtomb is called with buflen==1 that is not valid:
> 
> This situation is similar to[1] and invokes the "fortification checks are 
> typically stricter than what standards require to make the checks cheap 
> enough" comment that Andreas made.
> 
> The standard says[2] that up to MB_CUR_MAX bytes are stored into the input 
> buffer.  It appears to me that writing out zeroes to the extent of MB_CUR_MAX 
> bytes is also legitimate behaviour as long as the return value indicates the 
> byte length of the sequence.  Hence it makes sense to defensively always pass 
> a buffer of at least MB_CUR_MAX size to wcrtomb.

not quite:

        the wcrtomb() function shall determine the number of bytes needed to
        represent the character that corresponds to the wide character given by
        wc (including any shift sequences), and store the resulting bytes in
        the array whose first element is pointed to by s.  At most {MB_CUR_MAX}
        bytes are stored. 
 
That last part is a guarantee that the representation won't be longer
than a given limit.  But writing zeroes out violates the first statement,
if those bytes are not _needed_.

However, the call that you're reporting on is a different problem than that.

Offhand reading the code, it looks as if I didn't add 1 for the terminating
null (in the call to malloc) which is documented here:

       The wcsrtombs() function returns the number of bytes that make  up  the
       converted  part  of  multibyte  sequence, not including the terminating
       null byte.  If a wide character was encountered which could not be con‐
       verted, (size_t) -1 is returned, and errno set to EILSEQ.

> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=28989#c1
> [2] https://pubs.opengroup.org/onlinepubs/9699919799/functions/wcrtomb.html#
> 
> Martin
> 

-- 
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]