Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 21 Feb 2023 17:04:55 +0100
From: Markus Wichmann <>
Subject: Re: Re: [BUG] ioctl: overflow in implicit constant conversion

On Mon, Feb 20, 2023 at 09:26:05PM -0800, Ralph Little wrote:
> Hi,
> 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:
> Cheers,
> Ralph Little

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.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.