Re: Issue with unget_wch_sp and -D_FORTIFY_SOURCE

[Thomas Dickey]

On Mon, Apr 11, 2022 at 01:21:12PM +0530, Siddhesh Poyarekar wrote:
> On 09/04/2022 20:37, Thomas Dickey wrote:
> > I think the description is clear enough (if you disagree, the
> 
> I've been unable to convince anyone of my reading so obviously I've
> misinterpreted it.
> 
> > I misread that - wcrtomb shouldn't produce a trailing null,
> > and need not use that detail from wcsrtombs :-)
> > 
> > > >          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.
> > > 
> > > The glibc fortification (enabled by _FORTIFY_SOURCE) strictly requires the
> > > buffer to be MB_CUR_MAX long so despite fixing that bug (I trust your
> > 
> > I see this, apparently applying to wcrtomb:
> > 
> > https://ftp.gnu.org/old-gnu/Manuals/glibc-2.2.3/html_chapter/libc_6.html
> > 
> >     One word about the interface of the function: there is no parameter
> >     specifying the length of the array s.  Instead the function assumes
> >     that there are at least MB_CUR_MAX bytes available since this is the
> >     maximum length of any byte sequence representing a single character.
> >     So the caller has to make sure that there is enough space available,
> >     otherwise buffer overruns can occur.
> > 
> > so it's "documented" -- not in the manual page, but in the info document
> 
> Ahh, thanks for looking that up, I had missed it.  The info doc is the
> official glibc documentation...

The documentation needs some work (that "apparently" is a hint that
it's ambiguous).
 
> > (but since I don't see the same limitation in other implementations, am
> > unconvinced that it complies with POSIX).  By the way, the manual page
> > mentions POSIX, while that section of the info document does not:
> > 
> >     CONFORMING TO
> >            POSIX.1-2001, POSIX.1-2008, C99.
> > 
> > That paragraph in the info document doesn't allow for the case we're
> > discussing:  where the application determines (using the POSIX interface) 
> > the
> > number of bytes required, and uses that for the output buffer length.
> > If glibc writes past that number, it's no longer an implementation "quirk", 
> > but
> > a bug -- in glibc -- because it is not telling the application a correct 
> > number
> > for the required bytes.
> 
> ... so if it's documented in the manual then it's essentially a glibc
> extension that's evidently incompatible with POSIX.  That then explains the
> original rationale for implementing (back in 2007) the fortify check the way
> it has been.

I wouldn't call that an "extension", because it detracts from the feature
rather than providing an improvement.
 
> > So far, all I've seen is an issue with a limit-check which doesn't
> > agree with the expected value -- in glibc.  If the limit-check is
> > wrong (and glibc works as expected _without_ that check), then it's
> > a problem with the limit-check.
> 
> Not quite; the glibc implementation actually does assume internally that the
> end of the buffer is at MB_CUR_MAX, as it claims in its documentation.
> Depending on the iconv converter module, it may or may not overflow the
> bounds of the input buffer while writing to it.  It's just that without
> fortification there's no deliberate, preemptive abort.

sure - but it's a bug (I fix bugs that are older than that)

> We're discussing this here[1], I'll loop you into that conversation so that
> it's all in one place.
> 
> Siddhesh
> 
> [1] https://sourceware.org/pipermail/libc-alpha/2022-April/137626.html

-- 
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net
ftp://ftp.invisible-island.net

signature.asc
Description: PGP signature