From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 13849 invoked from network); 21 Feb 2023 16:58:16 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 21 Feb 2023 16:58:16 -0000 Received: (qmail 11819 invoked by uid 550); 21 Feb 2023 16:58:14 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 11785 invoked from network); 21 Feb 2023 16:58:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=SKRLwY/NtAJwdpNYjlk13cjlNw4B5LJCS11qBGKvJDE=; b=Tfm2ikiyccZHQyC+FydxALwEI9cl8abDJKbS2ghHB3wnKPTv9QR7qYBQoDzfDJJG60 ZqFWZngF+8pZspOUdEdf2n7hmuef7PXvbbs7NwW/OUFTxaZ/QtTopk+mjy0+usgLZ5fm NSH2uV4m37ynDjz+vSm16EpLDThV9KpSGwAt7qLqAwN9XAnNgufc4epFHzl0SwWTCIWx F1czx66zZ1VQ6ihhkMz4ghS7uDmEY3fCHdv/SVh+u/Glb4decB2Ik9Qb/qvXIZe39qj7 dAz9a0eO6H0apdS2BPPffcwx7JMwJKr6lZ4wEUbJzA75SRGj/7ApEDE3+w8bkzETgU6c nymA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=SKRLwY/NtAJwdpNYjlk13cjlNw4B5LJCS11qBGKvJDE=; b=o894cTm79C1Nnx01fIJil8DFHN+rGMe1J8Pt22dpcYvICMxv423t5+aWapEqud6lhT kpDAr+LRXfZ7Ejt5AMP1yYE6abYj80OWdQul1A6jZ4a3SB6PBiIVytdQaeYpTbvMbng6 AV16Uxsongx0cAHPEn5CCpfU0Bg9EsQvkqNXbfs5k5iiY+wbo4xQMs5SFbX2F4olpm6R GcES0/Yh/1vj2VAiFLhLiybHWnH95eq8weTfBMSCyYN4FLXZgKktiqqFsbW24Z18zrZi a+TNKZ/hS9uEj3E5VfQXiIp+jqfx5ibD3iV54Ak7QkZ3dE4L0lTEk8NoKz+82gptIHQ+ SR4w== X-Gm-Message-State: AO0yUKWEJbSf7h1XeAPd0r+yGSKQrexWYLh7561vKrB8XKyvvZoMPupx 8P82XzODy4s0YxmHlCrUnPC0MOl1tTxszLr6v2wXTYT2qMY= X-Google-Smtp-Source: AK7set9Myn9DY9KpMNVwaF1qJ0I+cAC+cS+hxOgfPPmpF/Fila9S4DBhwZl3YHDBRi6sHkT6oNO87nFydAMdZr4zBlo= X-Received: by 2002:a05:6870:ed86:b0:163:260e:8965 with SMTP id fz6-20020a056870ed8600b00163260e8965mr848184oab.263.1676998681583; Tue, 21 Feb 2023 08:58:01 -0800 (PST) MIME-Version: 1.0 References: <99826a90-6658-099e-9df8-d0bba78b8f0f@gmail.com> <20230221160455.GF1903@voyager> In-Reply-To: <20230221160455.GF1903@voyager> From: Jeffrey Walton Date: Tue, 21 Feb 2023 11:57:50 -0500 Message-ID: To: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [musl] Re: [BUG] ioctl: overflow in implicit constant conversion 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: > > > > https://www.openwall.com/lists/musl/2020/01/20/2 > > > > 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: > > > > https://gitlab.alpinelinux.org/alpine/aports/-/issues/7580#note_287168 > [...] > 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 . Jeff