mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: Re: #define __MUSL__ in features.h
Date: Thu, 15 Mar 2018 15:37:47 -0400	[thread overview]
Message-ID: <20180315193747.GL1436@brightrain.aerifal.cx> (raw)
In-Reply-To: <CAFdMc-0TQceAKH28wtAUxMoh6UBoynb_=85Qrrh-G-6n1R0tQg@mail.gmail.com>

On Thu, Mar 15, 2018 at 04:00:37PM -0300, dgutson . wrote:
> On Thu, Mar 15, 2018 at 3:53 PM, Rich Felker <dalias@libc.org> wrote:
> 
> > On Thu, Mar 15, 2018 at 03:48:32PM -0300, Martin Galvan wrote:
> > > 2018-03-15 15:39 GMT-03:00 Rich Felker <dalias@libc.org>:
> > > >> (e.g. the FD* issue reported by Martin Galvan).
> > > >
> > > > That's not a bug. It's compiler warnings being wrongly produced for a
> > > > system header, probably because someone added -I/usr/include or
> > > > similar (normally GCC suppresses these).
> > >
> > > I'm certain we didn't add -I/usr/include or something similar. Could
> > > you test this yourself to confirm it's not a bug?
> >
> > In any case it's not a bug in musl. The code is perfectly valid C. If
> > the compiler is producing a warning for it, either ignore it or ask
> > the compiler to stop.
> >
> > > The compiler warnings aren't being wrongly produced. musl will indeed
> > > perform a signed-to-unsigned conversion here.
> >
> > Because that's how the C language works.
> >
> 
> it is a potential vulnerability:
> https://cwe.mitre.org/data/definitions/195.html
> https://wiki.sei.cmu.edu/confluence/display/c/INT31-C.+Ensure+that+integer+conversions+do+not+result+in+lost+or+misinterpreted+data
> https://wiki.sei.cmu.edu/confluence/display/c/INT30-C.+Ensure+that+unsigned+integer+operations+do+not+wrap
> 
> Can you ensure it is rocksolid and the signed integer will NEVER be a
> negative value?

FD_* have undefined behavior if the argument is outside the range of
FD_SETSIZE. We could trap this (and if you use fortify headers, they
do) but doing so breaks applications that wrongly allocate larger
space for fd_set buffers for the sake of intentionally using larger fd
values than are possible with the select API.

The behavior of the code with or without the cast to unsigned added is
_exactly the same_. There is no bug here that is fixed by the proposed
patch. The warning is telling you that, if you don't understand how
integer promotions work in C, the code might not do what you expected
it to do. The fact that you seem to think adding a cast "fixes a bug"
is demonstrating how harmful the whole cult around compiler warnings
is: it's not about using them as hints to check your code and make
sure it's doing what you want, but instead about making the warning go
away without actually changing anything.

Rich


  parent reply	other threads:[~2018-03-15 19:37 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-15 15:55 dgutson .
2018-03-15 18:39 ` Rich Felker
2018-03-15 18:48   ` Martin Galvan
2018-03-15 18:53     ` Rich Felker
2018-03-15 19:00       ` dgutson .
2018-03-15 19:13         ` dgutson .
2018-03-15 19:42           ` Rich Felker
2018-03-15 20:16           ` u-uy74
2018-03-15 20:44             ` u-uy74
2018-03-15 19:37         ` Rich Felker [this message]
2018-03-15 19:42           ` dgutson .
2018-03-15 19:02       ` Martin Galvan
2018-03-15 19:32         ` Rich Felker
2018-03-15 19:37           ` dgutson .
2018-03-15 19:43             ` Rich Felker
2018-03-15 19:52               ` dgutson .
2018-03-15 21:46           ` Szabolcs Nagy
2018-03-15 22:38             ` Rich Felker
2018-03-15 18:51   ` dgutson .
2018-03-15 21:06     ` Markus Wichmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180315193747.GL1436@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).