[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 11 Jun 2024 21:02:28 +0200
From: Ismael Luceno <ismael@...ev.co.uk>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: [PATCH] ioctl: Fix implicit constant conversion overflow
On 10/Jun/2024 12:04, Rich Felker wrote:
> On Mon, Jun 03, 2024 at 03:57:18AM +0200, Ismael Luceno wrote:
<...>
> > An explicit cast at _IOC instead would make sense to me, but what
> > could break in your opinion?
>
> I'm not sure. It needs investigation. There might have been some
> concern with breakage from kernel headers that define ioctl numbers
> or something. I just remember this hasn't been as simple as it
> sounds from past times it came up..
The following headers use the _IOC macro:
asm/zcrypt.h (on S390)
asm-generic/ioctls.h
linux/hiddev.h
linux/hidraw.h
linux/input.h
linux/joystick.h
linux/uinput.h
linux/usbdevice_fs.h
linux/vboxguest.h
sound/sb16_csp.h
xen/evtchn.h
xen/gntalloc.h
xen/gntdev.h
xen/privcmd.h
None of these seem to pose a problem.
The only problem I see is if someone tried to cast it to a larger
signed type, which would be definitely a bug in their code, otherwise,
casting it to any unsigned type and back shoulld be fine.
Probably POSIX is wrong here, and it should be uint32_t for better
compatibility...
Thoughts?
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.
