This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] avoid buffer overflow in sunrpc clnt_create (BZ #22542)
- From: Paul Eggert <eggert at cs dot ucla dot edu>
- To: Martin Sebor <msebor at gmail dot com>, Carlos O'Donell <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 6 Feb 2018 16:54:45 -0800
- Subject: Re: [PATCH] avoid buffer overflow in sunrpc clnt_create (BZ #22542)
- Authentication-results: sourceware.org; auth=none
- References: <f6a8c32f-f524-9ebb-03bc-4484f8a80a16@gmail.com> <2ab77d63-7f68-1c60-40d2-71a9bef5f21f@cs.ucla.edu> <20171204015531.GA8729@altlinux.org> <9588ad22-bb91-5364-2217-4813857ee529@cs.ucla.edu> <20180206210601.GA23713@altlinux.org>
On 02/06/2018 01:06 PM, Dmitry V. Levin wrote:
On Mon, Dec 04, 2017 at 12:04:12AM -0800, Paul Eggert wrote: >> Dmitry V. Levin wrote: >>> Do people really expect that? Assuming
that people are aware >>> of linux kernel behaviour, why would they
expect that? >> >> These days, it's because strncpy format is obsolete
and is not something >> programmers are ordinarily aware of. When in
doubt (which there seems to be >> here), glibc should use
null-terminated strings rather than strncpy format. > > Is there any
statistics what programmers are ordinarily aware of? > > I have no
doubts that some valid code[1] no longer compiles with >
-Werror=stringop-truncation, and the only plausible fix is to mark >
struct sockaddr_un.sun_path with __attribute_nonstring__. If memory
serves, a problem is that some glibc-related uses of struct
sockaddr_un.sun_path assume strncpy format and others do not. If so,
marking it with __attribute_nonstring__ will pacify uses in some cases
(such as the one you mention), while masking bugs in others. If there's
some doubt about the intended format of this buffer, then it's safer for
everybody to stick to null-terminated strings in it.
For unusual programs such as the test program you mention, it's easy
enough to use memcpy instead of strncpy to test buffers that are not
null-terminated. Using memcpy would be better for this kind of test
anyway, since it would allow a test case where the null byte at the end
of the string is not followed by nulls all the way to the end of the buffer.