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 5F4F9C388F7 for ; Thu, 22 Oct 2020 21:28:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AD12624640 for ; Thu, 22 Oct 2020 21:28:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AD12624640 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=zeniv.linux.org.uk Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B52626B0062; Thu, 22 Oct 2020 17:28:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id ADAE16B005D; Thu, 22 Oct 2020 17:28:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 97AC16B006C; Thu, 22 Oct 2020 17:28:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0171.hostedemail.com [216.40.44.171]) by kanga.kvack.org (Postfix) with ESMTP id 6247E6B005D for ; Thu, 22 Oct 2020 17:28:48 -0400 (EDT) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 0B234180AD81A for ; Thu, 22 Oct 2020 21:28:48 +0000 (UTC) X-FDA: 77400851136.02.flock76_2f139bb27254 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin02.hostedemail.com (Postfix) with ESMTP id D7D7C102BE5E5; Thu, 22 Oct 2020 21:28:47 +0000 (UTC) X-HE-Tag: flock76_2f139bb27254 X-Filterd-Recvd-Size: 4726 Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [195.92.253.2]) by imf06.hostedemail.com (Postfix) with ESMTP; Thu, 22 Oct 2020 21:28:47 +0000 (UTC) Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVi8K-006V84-LA; Thu, 22 Oct 2020 21:28:28 +0000 Date: Thu, 22 Oct 2020 22:28:28 +0100 From: Al Viro To: Eric Biggers Cc: Linus Torvalds , Nick Desaulniers , Matthew Wilcox , David Laight , Christoph Hellwig , David Hildenbrand , Greg KH , "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" Message-ID: <20201022212828.GZ3576660@ZenIV.linux.org.uk> References: <20201022090155.GA1483166@kroah.com> <5fd6003b-55a6-2c3c-9a28-8fd3a575ca78@redhat.com> <20201022132342.GB8781@lst.de> <8f1fff0c358b4b669d51cc80098dbba1@AcuMS.aculab.com> <20201022164040.GV20115@casper.infradead.org> <20201022205932.GB3613750@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201022205932.GB3613750@gmail.com> 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 01:59:32PM -0700, Eric Biggers wrote: > Also note the following program succeeds on Linux 5.9 on x86_64. On kernels > that have this bug, it should fail. (I couldn't get it to actually fail, so it > must depend on the compiler and/or the kernel config...) It doesn't. See https://www.spinics.net/lists/linux-scsi/msg147836.html for discussion of that mess. ssize_t vfs_readv(struct file *file, const struct iovec __user *vec, unsigned long vlen, loff_t *pos, rwf_t flags) { struct iovec iovstack[UIO_FASTIOV]; struct iovec *iov = iovstack; struct iov_iter iter; ssize_t ret; ret = import_iovec(READ, vec, vlen, ARRAY_SIZE(iovstack), &iov, &iter); if (ret >= 0) { ret = do_iter_read(file, &iter, pos, flags); kfree(iov); } return ret; } and import_iovec() takes unsigned int as the third argument, so it *will* truncate to 32 bits, no matter what. Has done so since 0504c074b546 "switch {compat_,}do_readv_writev() to {compat_,}import_iovec()" back in March 2015. Yes, it was an incompatible userland ABI change, even though nothing that used glibc/uclibc/dietlibc would've noticed. Better yet, up until 2.1.90pre1 passing a 64bit value as the _first_ argument of readv(2) used to fail with -EBADF if it was too large; at that point it started to get quietly truncated to 32bit first. And again, no libc users would've noticed (neither would anything except deliberate regression test looking for that specific behaviour). Note that we also have process_madvise(2) with size_t for vlen (huh? It's a number of array elements, not an object size) and process_vm_{read,write}v(2), that have unsigned long for the same thing. And the last two *are* using the same unsigned long from glibc POV.