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 3A210C4363A for ; Thu, 22 Oct 2020 18:13:15 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4E1B6223BF for ; Thu, 22 Oct 2020 18:13:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4E1B6223BF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 4A87F6B0062; Thu, 22 Oct 2020 14:13:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 426E76B0071; Thu, 22 Oct 2020 14:13:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 251836B006E; Thu, 22 Oct 2020 14:13:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0162.hostedemail.com [216.40.44.162]) by kanga.kvack.org (Postfix) with ESMTP id E179A6B0068 for ; Thu, 22 Oct 2020 14:13:11 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 628201EE6 for ; Thu, 22 Oct 2020 18:13:11 +0000 (UTC) X-FDA: 77400358182.07.fear29_1217ab627253 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin07.hostedemail.com (Postfix) with ESMTP id 3E9FD1803F9AC; Thu, 22 Oct 2020 18:13:11 +0000 (UTC) X-HE-Tag: fear29_1217ab627253 X-Filterd-Recvd-Size: 6026 Received: from mout-xforward.kundenserver.de (mout-xforward.kundenserver.de [82.165.159.37]) by imf28.hostedemail.com (Postfix) with ESMTP; Thu, 22 Oct 2020 18:13:10 +0000 (UTC) Received: from mail-qk1-f172.google.com ([209.85.222.172]) by mrelayeu.kundenserver.de (mreue108 [213.165.67.113]) with ESMTPSA (Nemesis) id 1MUXh8-1kw1em1eBU-00QPD5; Thu, 22 Oct 2020 20:13:08 +0200 Received: by mail-qk1-f172.google.com with SMTP id z6so2567639qkz.4; Thu, 22 Oct 2020 11:13:07 -0700 (PDT) X-Gm-Message-State: AOAM532DjpzxNXSX3xEV5qtdK6rNBD4oDaO+ueUuQ664xQrGnYXOism9 3fYjeROixsSLfE4NQjSmwMsbHbdRzndX6AiLV+U= X-Google-Smtp-Source: ABdhPJzQkCdsAEzOH97JlGBle9/SdVwDzxpXvJqxWrt3Kp+S5wDOXz+F9Pi6NLPQk2A3sIN6d0NiTlYy33fWAPxqKDk= X-Received: by 2002:a05:620a:215d:: with SMTP id m29mr2210077qkm.138.1603390386870; Thu, 22 Oct 2020 11:13:06 -0700 (PDT) MIME-Version: 1.0 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> <8f1fff0c358b4b669d51cc80098dbba1@AcuMS.aculab.com> In-Reply-To: From: Arnd Bergmann Date: Thu, 22 Oct 2020 20:12:49 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c" To: Nick Desaulniers Cc: David Laight , Christoph Hellwig , David Hildenbrand , Greg KH , Al Viro , "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" Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:cmvWBeUP1cXHElcL0Sqg7++15g8WPI514OkbXuIbq5oqKC8cKlD G3mapaEFVnXu5c6kMAxRw5bOpHdFx8QwaEZQ4Fd4athIoaOf5UNsvr9ODnHcv0+cQgmxpSu CmQcm5ONz6sRNX3qDPseV9Xdoc4JskTmjPUkmQ5H4PTCLqS9PulV0P/loTNJCfsGtNj+Vi1 /EEo+TJrURzpMO95JGkCg== X-UI-Out-Filterresults: junk:10;V03:K0:756/v1MAA5Y=:lYh2/wUlGzn923ikLc161xYX 83WztoOd9OJrUpC+g84mqchi/9sN/btnf0ywvRenxmYvn1njOi5slsa0LgQ5y/CTEMh8L9m1w 3X3MObovxzdWHBMjzSRXDaQ3iCira+kkDxhymldisNPyVeVNberMo0NThQON8suZulcvodCuU M1G2p0yWIMj+iWvW9bCzDuUF3zqklB0drAmqYr7XERGTOP8WVegH2tUSmnDC6b+nnLu2iNb4n nuQYwuFbSfsoUi+IcAT1juVUtbtiHGR2yDBDqzxHHpj8ct+YLS1IYe4a/rRyZWPhUH4abjIki GjmntumJw+sp6ys0SOkjksrYKCSuzlaKC+HWtIMfGlbeJtLeoBgHPCyqmSpk4VrZr1utfuyW8 KnxxAx76n0yda4NzNkEgk5oVaqPrQ6avv2IzXm6to7QF8KOpUvvtRgz9cvRodx4sCtXI0+Yu1 yTKRlbW5iQOmYk8i4XrpZg7F89iw/5r89ROGbx9SuLO7qPFm5WmMBw28YHGhbM3vkiLHH5rA= = 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: On Thu, Oct 22, 2020 at 7:54 PM Nick Desaulniers wrote: > On Thu, Oct 22, 2020 at 9:35 AM David Laight wrote: > > > > 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. > > Why not x86-64? Wouldn't it be *any* LP64 ISA? x86-64 is slightly special because most instructions on a 32-bit argument clear the upper 32 bits, while on most architectures the same instruction would leave the upper bits unchanged. > Attaching a patch that uses the proper width, but I'm pretty sure > there's still a signedness issue . Greg, would you mind running this > through the wringer? I would not expect this to change anything for the bug that Greg is chasing, unless there is also a bug in clang. In the version before the patch, we get a 64-bit argument from user space, which may consist of the intended value in the lower bits plus garbage in the upper bits. However, vlen only gets passed down into import_iovec() without any other operations on it, and ince import_iovec takes a 32-bit argument, this is where it finally gets narrowed. After your patch, the SYSCALL_DEFINE3() does the narrowing conversion with the same clearing of the upper bits. If there is a problem somewhere leading up to import_iovec(), it would have to in some code that expects to get a 32-bit register argument but gets called with a register that has garbage in the upper bits /without/ going through a correct sanitizing function like SYSCALL_DEFINE3(). Arnd