Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp1354514ybn; Wed, 2 Oct 2019 14:56:57 -0700 (PDT) X-Google-Smtp-Source: APXvYqzuPNcJleNMDyXvKKXGofw562igzN0nuWc8MLc1qSpcdw+ZBny/BPtGBAcCgECTPJsIlFPI X-Received: by 2002:a17:906:fac5:: with SMTP id lu5mr5057866ejb.71.1570053417760; Wed, 02 Oct 2019 14:56:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570053417; cv=none; d=google.com; s=arc-20160816; b=ZSOxopGTtAFqrNaYQr+qkOsCCTfzJzNN4PA6IX5Uxsa27w3i+UTT9aMH46i4i3z3TY tE5ozp3zWGCjL7xJCFAdpuXtTQlA5BJyf2sw+uNWcLpgitJNIeukg26CtMJPpT4oupyq ofm9oJaUpfEJy8/j6s5R/C5GMizLS5xpYTTCoB0XN+nwJ1D4HP4Ew9vq54oQ8sAdnpjX X+PjDRpYnZqskMDzBMOmcRPYDEHFdiEilUsvPwNUh2tKkRLUEwxSyYjijMvDsUIrj38i eX+/d8qRDNGeDSumUVBkWXrMapQX74inoOt+/d50/FchdIV6/a+ujd4ybmVN9obco3NV t/KA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:mime-version:user-agent:date:message-id:cc:subject :from:to; bh=ah0fcjgrmPtpwiDIE11q0vi0hEKds1vlYZthS318zoA=; b=EiAjgCTJHrVZvFDYVosqg2QNU0zVvk3Bsf/SF+wxR48m2bbZYo/dN/RANJaEYVujpq feSSFSnxS43QkYjDBJTZgXz3obdzKyfVkROm0TLLOpHSAvNh+M75EBTSVNl4Vvv4Bcjo 0Gx+yXTKtXAIFUc8bTZiorOVgiXRb1bzV1IRJhI3VCv0ZJG6lN39tZEbckQPu9TGXU/n EVIQhCxEA0EpWUWQ9U/HMhx0NV19pR23//T1no3cpSNJxGkEFqmY0UQtqxR00SIXU/ce M2NR/UuLfIA4f14GQRfKmlb2sPQHL+gqMRJKnhcglVlwSezb0wu6kUexZkhqVxzdZOHL Gsag== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y23si260600edb.208.2019.10.02.14.56.33; Wed, 02 Oct 2019 14:56:57 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729467AbfJBVR4 (ORCPT + 99 others); Wed, 2 Oct 2019 17:17:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55148 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728713AbfJBVR4 (ORCPT ); Wed, 2 Oct 2019 17:17:56 -0400 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C5ACBA44AC6; Wed, 2 Oct 2019 21:17:55 +0000 (UTC) Received: from [IPv6:::1] (ovpn04.gateway.prod.ext.phx2.redhat.com [10.5.9.4]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6BB2160BF3; Wed, 2 Oct 2019 21:17:55 +0000 (UTC) To: Linux Kernel Mailing List , fsdevel From: Eric Sandeen Subject: [PATCH] vfs: Fix EOVERFLOW testing in put_compat_statfs64 Cc: Al Viro , Linus Torvalds Message-ID: <6a26185f-f188-0049-b153-1541d7a514b0@redhat.com> Date: Wed, 2 Oct 2019 16:17:54 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.redhat.com [10.5.110.68]); Wed, 02 Oct 2019 21:17:56 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Today, put_compat_statfs64() disallows nearly any field value over 2^32 if f_bsize is only 32 bits, but that makes no sense. compat_statfs64 is there for the explicit purpose of providing 64-bit fields for f_files, f_ffree, etc. And f_bsize is always only 32 bits. As a result, 32-bit userspace gets -EOVERFLOW for i.e. large file counts even with -D_FILE_OFFSET_BITS=64 set. In reality, only f_bsize and f_frsize can legitimately overflow (fields like f_type and f_namelen should never be large), so test only those fields. This bug was discussed at length some time ago, and this is the proposal Al suggested at https://lkml.org/lkml/2018/8/6/640. It seemed to get dropped amid the discussion of other related changes, but this part seems obviously correct on its own, so I've picked it up and sent it, for expediency. Fixes: 64d2ab32efe3 ("vfs: fix put_compat_statfs64() does not handle errors") Signed-off-by: Eric Sandeen --- Note, if it'd be better form to add: From: Al Viro please do so. Thanks, -Eric diff --git a/fs/statfs.c b/fs/statfs.c index eea7af6f2f22..2616424012ea 100644 --- a/fs/statfs.c +++ b/fs/statfs.c @@ -318,19 +318,10 @@ COMPAT_SYSCALL_DEFINE2(fstatfs, unsigned int, fd, struct compat_statfs __user *, static int put_compat_statfs64(struct compat_statfs64 __user *ubuf, struct kstatfs *kbuf) { struct compat_statfs64 buf; - if (sizeof(ubuf->f_bsize) == 4) { - if ((kbuf->f_type | kbuf->f_bsize | kbuf->f_namelen | - kbuf->f_frsize | kbuf->f_flags) & 0xffffffff00000000ULL) - return -EOVERFLOW; - /* f_files and f_ffree may be -1; it's okay - * to stuff that into 32 bits */ - if (kbuf->f_files != 0xffffffffffffffffULL - && (kbuf->f_files & 0xffffffff00000000ULL)) - return -EOVERFLOW; - if (kbuf->f_ffree != 0xffffffffffffffffULL - && (kbuf->f_ffree & 0xffffffff00000000ULL)) - return -EOVERFLOW; - } + + if ((kbuf->f_bsize | kbuf->f_frsize) & 0xffffffff00000000ULL) + return -EOVERFLOW; + memset(&buf, 0, sizeof(struct compat_statfs64)); buf.f_type = kbuf->f_type; buf.f_bsize = kbuf->f_bsize;