From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2B444C388F7 for ; Thu, 22 Oct 2020 19:25:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D560924656 for ; Thu, 22 Oct 2020 19:25:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S370162AbgJVTZP (ORCPT ); Thu, 22 Oct 2020 15:25:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51098 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S370155AbgJVTZP (ORCPT ); Thu, 22 Oct 2020 15:25:15 -0400 Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [IPv6:2002:c35c:fd02::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 81851C0613CE; Thu, 22 Oct 2020 12:25:14 -0700 (PDT) Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVgCo-006RRM-M6; Thu, 22 Oct 2020 19:24:58 +0000 Date: Thu, 22 Oct 2020 20:24:58 +0100 From: Al Viro To: Nick Desaulniers Cc: Arnd Bergmann , David Laight , Christoph Hellwig , David Hildenbrand , Greg KH , "kernel-team@android.com" , Andrew Morton , Jens Axboe , David Howells , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "linux-mips@vger.kernel.org" , "linux-parisc@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" , "linux-s390@vger.kernel.org" , "sparclinux@vger.kernel.org" , "linux-block@vger.kernel.org" , "linux-scsi@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "linux-aio@kvack.org" , "io-uring@vger.kernel.org" , "linux-arch@vger.kernel.org" , "linux-mm@kvack.org" , "netdev@vger.kernel.org" , "keyrings@vger.kernel.org" , "linux-security-module@vger.kernel.org" Subject: Re: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c" Message-ID: <20201022192458.GV3576660@ZenIV.linux.org.uk> References: <20201022090155.GA1483166@kroah.com> <5fd6003b-55a6-2c3c-9a28-8fd3a575ca78@redhat.com> <20201022132342.GB8781@lst.de> <8f1fff0c358b4b669d51cc80098dbba1@AcuMS.aculab.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Al Viro Precedence: bulk List-ID: X-Mailing-List: keyrings@vger.kernel.org On Thu, Oct 22, 2020 at 12:04:52PM -0700, Nick Desaulniers wrote: > Passing an `unsigned long` as an `unsigned int` does no such > narrowing: https://godbolt.org/z/TvfMxe (same vice-versa, just tail > calls, no masking instructions). > So if rw_copy_check_uvector() is inlined into import_iovec() (looking > at the mainline@1028ae406999), then children calls of > `rw_copy_check_uvector()` will be interpreting the `nr_segs` register > unmodified, ie. garbage in the upper 32b. FWIW, void f(unsinged long v) { if (v != 1) printf("failed\n"); } void g(unsigned int v) { f(v); } void h(unsigned long v) { g(v); } main() { h(0x100000001); } must not produce any output on a host with 32bit int and 64bit long, regardless of the inlining, having functions live in different compilation units, etc. Depending upon the calling conventions, compiler might do truncation in caller or in a callee, but it must be done _somewhere_.