From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <musl-return-20998-ml=inbox.vuxu.org@lists.openwall.com>
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-3.1 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4,
	RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham
	autolearn_force=no version=3.4.4
Received: from second.openwall.net (second.openwall.net [193.110.157.125])
	by inbox.vuxu.org (Postfix) with SMTP id 053E723D6D
	for <ml@inbox.vuxu.org>; Tue, 11 Jun 2024 21:02:42 +0200 (CEST)
Received: (qmail 1705 invoked by uid 550); 11 Jun 2024 19:02:37 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Reply-To: musl@lists.openwall.com
Received: (qmail 1673 invoked from network); 11 Jun 2024 19:02:37 -0000
Date: Tue, 11 Jun 2024 21:02:28 +0200
From: Ismael Luceno <ismael@iodev.co.uk>
To: Rich Felker <dalias@libc.org>
Cc: musl@lists.openwall.com
Message-ID: <ZmifRCsMf7Y7Wxa6@pirotess>
References: <20240601010328.27409-1-ismael@iodev.co.uk>
 <20240601023429.GJ10433@brightrain.aerifal.cx>
 <Zlvgdr9kztoNKDLz@pirotess>
 <20240602225026.GK10433@brightrain.aerifal.cx>
 <Zl0i_i0yTeLyjCOZ@pirotess>
 <20240610160408.GN10433@brightrain.aerifal.cx>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240610160408.GN10433@brightrain.aerifal.cx>
Subject: Re: [musl] [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?