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.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 8B480C388F9 for ; Thu, 22 Oct 2020 16:35:26 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 03BEE2463F for ; Thu, 22 Oct 2020 16:35:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 03BEE2463F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=ACULAB.COM Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id DB5C06B0070; Thu, 22 Oct 2020 12:35:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D3E976B0072; Thu, 22 Oct 2020 12:35:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BE03E6B0071; Thu, 22 Oct 2020 12:35:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0026.hostedemail.com [216.40.44.26]) by kanga.kvack.org (Postfix) with ESMTP id 8EE6A6B006E for ; Thu, 22 Oct 2020 12:35:24 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 272A5180AD802 for ; Thu, 22 Oct 2020 16:35:24 +0000 (UTC) X-FDA: 77400111768.27.grass35_5503aaa27252 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin27.hostedemail.com (Postfix) with ESMTP id 057983D668 for ; Thu, 22 Oct 2020 16:35:23 +0000 (UTC) X-HE-Tag: grass35_5503aaa27252 X-Filterd-Recvd-Size: 5458 Received: from eu-smtp-delivery-151.mimecast.com (eu-smtp-delivery-151.mimecast.com [207.82.80.151]) by imf20.hostedemail.com (Postfix) with ESMTP for ; Thu, 22 Oct 2020 16:35:23 +0000 (UTC) Received: from AcuMS.aculab.com (156.67.243.126 [156.67.243.126]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-276-A1zb3avLNamAEPsIomTLEw-1; Thu, 22 Oct 2020 17:35:18 +0100 X-MC-Unique: A1zb3avLNamAEPsIomTLEw-1 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b:0:43c:695e:880f:8750) by AcuMS.aculab.com (fd9f:af1c:a25b:0:43c:695e:880f:8750) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 22 Oct 2020 17:35:17 +0100 Received: from AcuMS.Aculab.com ([fe80::43c:695e:880f:8750]) by AcuMS.aculab.com ([fe80::43c:695e:880f:8750%12]) with mapi id 15.00.1347.000; Thu, 22 Oct 2020 17:35:17 +0100 From: David Laight To: 'Christoph Hellwig' , David Hildenbrand CC: Greg KH , Al Viro , Nick Desaulniers , "kernel-team@android.com" , Andrew Morton , "Jens Axboe" , Arnd Bergmann , 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" Thread-Topic: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c" Thread-Index: AQHWqE5GNDfnH4y9nkGWtfqJueR1KKmjTCJQgAAN4UiAAAD2IIAAQY5tgAAwVkA= Date: Thu, 22 Oct 2020 16:35:17 +0000 Message-ID: <8f1fff0c358b4b669d51cc80098dbba1@AcuMS.aculab.com> References: <20201021233914.GR3576660@ZenIV.linux.org.uk> <20201022082654.GA1477657@kroah.com> <80a2e5fa-718a-8433-1ab0-dd5b3e3b5416@redhat.com> <5d2ecb24db1e415b8ff88261435386ec@AcuMS.aculab.com> <20201022090155.GA1483166@kroah.com> <5fd6003b-55a6-2c3c-9a28-8fd3a575ca78@redhat.com> <20201022132342.GB8781@lst.de> In-Reply-To: <20201022132342.GB8781@lst.de> Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C51A453 smtp.mailfrom=david.laight@aculab.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: From: Christoph Hellwig > Sent: 22 October 2020 14:24 >=20 > On Thu, Oct 22, 2020 at 11:36:40AM +0200, David Hildenbrand wrote: > > My thinking: if the compiler that calls import_iovec() has garbage in > > the upper 32 bit > > > > a) gcc will zero it out and not rely on it being zero. > > b) clang will not zero it out, assuming it is zero. > > > > But > > > > a) will zero it out when calling the !inlined variant > > b) clang will zero it out when calling the !inlined variant > > > > When inlining, b) strikes. We access garbage. That would mean that we > > have calling code that's not generated by clang/gcc IIUC. >=20 > Most callchains of import_iovec start with the assembly syscall wrappers. Wait... readv(2) defines: =09ssize_t readv(int fd, const struct iovec *iov, int iovcnt); But the syscall is defined as: SYSCALL_DEFINE3(readv, unsigned long, fd, const struct iovec __user *, vec, unsigned long, vlen) { return do_readv(fd, vec, vlen, 0); } I'm guessing that nothing actually masks the high bits that come from an application that is compiled with clang? The vlen is 'unsigned long' through the first few calls. So unless there is a non-inlined function than takes vlen as 'int' the high garbage bits from userspace are kept. Which makes it a bug in the kernel C syscall wrappers. They need to explicitly mask the high bits of 32bit arguments on arm64 but not x86-64. What does the ARM EABI say about register parameters? =09David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1= PT, UK Registration No: 1397386 (Wales)