bug-ncurses
[Top][All Lists]
Advanced

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

Issue with unget_wch_sp and -D_FORTIFY_SOURCE


From: Martin Liška
Subject: Issue with unget_wch_sp and -D_FORTIFY_SOURCE
Date: Wed, 6 Apr 2022 10:16:43 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0

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.

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

Martin



reply via email to

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