[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
signature.asc
Description: PGP signature
- Issue with unget_wch_sp and -D_FORTIFY_SOURCE, Martin Liška, 2022/04/06
- Re: Issue with unget_wch_sp and -D_FORTIFY_SOURCE,
Thomas Dickey <=
- Re: Issue with unget_wch_sp and -D_FORTIFY_SOURCE, Siddhesh Poyarekar, 2022/04/07
- Re: Issue with unget_wch_sp and -D_FORTIFY_SOURCE, Siddhesh Poyarekar, 2022/04/11
- Re: Issue with unget_wch_sp and -D_FORTIFY_SOURCE, Thomas Dickey, 2022/04/11
- Re: Issue with unget_wch_sp and -D_FORTIFY_SOURCE, Siddhesh Poyarekar, 2022/04/12
- Re: Issue with unget_wch_sp and -D_FORTIFY_SOURCE, Thomas Dickey, 2022/04/12