mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Jeffrey Walton <>
Subject: Re: [musl] Re: [BUG] ioctl: overflow in implicit constant conversion
Date: Tue, 21 Feb 2023 11:57:50 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <20230221160455.GF1903@voyager>

On Tue, Feb 21, 2023 at 11:05 AM Markus Wichmann <> wrote:
> On Mon, Feb 20, 2023 at 09:26:05PM -0800, Ralph Little wrote:
> > I have been picking up some old pending issues related to the SANE project.
> > One of our CI builds is on Alpine and it is generating warnings for ioctl()
> > calls from the musl library:
> >
> > |error: overflow in conversion from 'long unsigned int' to 'int' changes
> > value from '2147577985' to '-2147389311' [-Werror=overflow]
> > |
> > ||ioctl (fd, PPRSTATUS, &status);
> >
> > ||I see that Olaf Meeuwissen raised this issue a couple of years ago and the
> > discussion petered out somewhat and I don't believe that the issue was ever
> > really resolved:
> >
> >
> >
> > Is there any possibility that this could be addressed in the near future?
> > I see that Alpine have closed their issue and are not interested in patching
> > their downstream musl:
> >
> >
> [...]
> So, I had a look at it. As far as I can tell, the issue is that musl
> declares ioctl()'s second argument to be an int. Together with the other
> defintions, this means that any _IOC_READ constant will overflow and
> generate those warnings. Also, this is technically undefined behavior,
> as value bits are shifted into the sign bit of a signed integer.
> Linux itself defines the ioctl syscall to have a second argument of type
> unsigned int.
> So this issue could be resolved by simply making the second argument of
> the ioctl() function unsigned. Does that create ABI issues? To my
> knowledge, all ABIs pass ints and unsigned ints the same way. Even if on
> some 64-bit arch there was a sign extension at the top, only the low
> 32 bits are defined.

In this case, I think the best course of action is to cast a,b,c to
unsigned, then perform the shifts, and finally cast back to int. That
is what the C standard requires. And it should not mess with the ABI.

If the code remains undefined, then it is subject to removal by the
compiler. The casts, while ugly, keep the code in well defined
territory. Also, if anyone ever performs testing with
-fsantize=undefined, then the code will trigger real findings that
could keep the code from passing through a security gate (for those
folks who have to work in that kind of environment).

I've had to work bug reports that were a result of the missing casts
during shifts and rotates. It is not fun. I was able to track all of
them down with -fsantize=undefined .


  parent reply	other threads:[~2023-02-21 16:58 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-21  5:26 Ralph Little
2023-02-21 16:04 ` Markus Wichmann
2023-02-21 16:42   ` Florian Weimer
2023-02-21 16:53     ` alice
2023-02-21 16:57   ` Jeffrey Walton [this message]
2023-02-21 18:25     ` Ralph Little
2023-02-21 21:28     ` Markus Wichmann
2023-02-22  6:33       ` NRK
2023-02-22  3:17   ` Rich Felker
2023-02-22  4:23     ` Markus Wichmann
2023-02-22 15:53       ` Rich Felker

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:

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

  git send-email \ \ \ \

* 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

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).