Received: by 10.213.65.68 with SMTP id h4csp1120867imn; Wed, 28 Mar 2018 21:19:36 -0700 (PDT) X-Google-Smtp-Source: AIpwx49zLBLN3J9ce3WC5JU/W20DWrzpjwdx+kVB3m4Qes0ujqljZnaq/rVV5q9gLpgeavhbYvxR X-Received: by 10.98.220.86 with SMTP id t83mr5092062pfg.60.1522297176483; Wed, 28 Mar 2018 21:19:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522297176; cv=none; d=google.com; s=arc-20160816; b=kgAWFt+dQw+NYxuDziR/vmZ3Lx6sSZdInitq9ex8a73vsr01PO+GXA1oJWmwf6lYuO QZEW4NhEkI8H3qzM96MBW+e77QTjv6iPOBBXHe5ntHUdTrFTTv9QZTMCu/s9OtwDLHG6 eNIQ1C+8vm3mMHYs8QTJ+YJ3UQIn2GtHXu94Kmf32IrzATmlyP8yxtQREg9XxWcrF4Mp 1rSOAkq5yp93XzXwxs3SArfEbBSsv6G6QaVfvgFq4twjF2m5l4odrFDqGqE0/7MPG0Kp QZ0eQuCjU+L7gzAuCq1yUsC6vs2rQNBGLfOhuAddXygL4CxxN7Djl9OTBMKkkWqzf3B5 kT5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature:arc-authentication-results; bh=mBc7ERavmfRSdxeXynHW9K/+znG5yn8q02TYO7NFG40=; b=uqw7r5W1F+JLfOujpSUAbcSHSfbWXwBfjFuMCPeZ4QEJd743+lOOoKLl3bp9hLFNhK gRDIuNBBW9fSdKJStJvddMtw+zNzG2vSbNkiwcKm+sqm0mFaL2m0bs0TPYwMc+QAT0E5 F1WnloGtE68RNwdR9GatmXRVJmoz8gPbX7FuV0U2SVTGZZ9MI6q8VHk0egLQOhd8rChY o1Z0XqrRGhBIEd6XkGTs4oUgl2tlOjWo0SKCa0jUnogsFnhRmZQ8FHHhPXqy9pT7DLDC +19N1O26EDIZxXAjgRC/TyVj2B4yex5poBGhe90bUB8PVKSKdQy/rOPkhV5Q4wuYYFp+ a/rA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=scIv/+FV; 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=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f8-v6si5143323plk.538.2018.03.28.21.19.22; Wed, 28 Mar 2018 21:19:36 -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; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=scIv/+FV; 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=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752027AbeC2ESS (ORCPT + 99 others); Thu, 29 Mar 2018 00:18:18 -0400 Received: from userp2120.oracle.com ([156.151.31.85]:57024 "EHLO userp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750708AbeC2ESQ (ORCPT ); Thu, 29 Mar 2018 00:18:16 -0400 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w2T45QL3030687; Thu, 29 Mar 2018 04:17:06 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : in-reply-to : references; s=corp-2017-10-26; bh=mBc7ERavmfRSdxeXynHW9K/+znG5yn8q02TYO7NFG40=; b=scIv/+FVTWYdIKyDqgJIUwu7fhkxGGgXhZSnBRZxnxn5pOwCJOXo+PZI1VlaCsaVkk82 5Q2oLOIKAR/AS3+YWHg1givY54I4851CWEvnecO9kJ+9g31U88LWsXCts/yiEL4ZhJtc Rw52Q9LNoo6LrRTMhWINcwlZup/YyzFN4LIDFl3R4Pbk3jXVBm8Gy4KD3beAoG9nMnaY F4rfgKnmsz8Eg+2OeP0/t3B9CJHH+cxng6gLRp/mDJouelta7lkVgFw1O5ALCLa7S9vs lyfe7QPM90j4ieuwnx30U7Ve3bNo12dpL8JLDPwdhJTbFA+0UzGBBMFqs9M7+vtCUUtm qw== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2120.oracle.com with ESMTP id 2h0rs881vw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 29 Mar 2018 04:17:06 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w2T4H5ON007876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 29 Mar 2018 04:17:06 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w2T4H4YQ011133; Thu, 29 Mar 2018 04:17:05 GMT Received: from monkey.oracle.com (/98.246.252.205) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 28 Mar 2018 21:17:04 -0700 From: Mike Kravetz To: linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: Michal Hocko , Yisheng Xie , "Kirill A . Shutemov" , Nic Losby , Dan Rue , Andrew Morton , Mike Kravetz , stable@vger.kernel.org Subject: [PATCH 1/1] hugetlbfs: fix bug in pgoff overflow checking Date: Wed, 28 Mar 2018 21:16:56 -0700 Message-Id: <20180329041656.19691-2-mike.kravetz@oracle.com> X-Mailer: git-send-email 2.13.6 In-Reply-To: <20180329041656.19691-1-mike.kravetz@oracle.com> References: <20180329041656.19691-1-mike.kravetz@oracle.com> X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8846 signatures=668695 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803290046 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This is a fix for a regression in 32 bit kernels caused by an invalid check for pgoff overflow in hugetlbfs mmap setup. The check incorrectly specified that the size of a loff_t was the same as the size of a long. The regression prevents mapping hugetlbfs files at offset greater than 4GB on 32 bit kernels. Fix the check by using sizeof(loff_t) to get size. In addition, make sure pgoff + length can be represented by a signed long huge page offset. This check is only necessary on 32 bit kernels. Fixes: 63489f8e8211 ("hugetlbfs: check for pgoff value overflow") Cc: Reported-by: Dan Rue Signed-off-by: Mike Kravetz --- fs/hugetlbfs/inode.c | 22 +++++++++++++++++----- 1 file changed, 17 insertions(+), 5 deletions(-) diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c index b9a254dcc0e7..8450a1d75dfa 100644 --- a/fs/hugetlbfs/inode.c +++ b/fs/hugetlbfs/inode.c @@ -116,7 +116,8 @@ static void huge_pagevec_release(struct pagevec *pvec) * bit into account. */ #define PGOFF_LOFFT_MAX \ - (((1UL << (PAGE_SHIFT + 1)) - 1) << (BITS_PER_LONG - (PAGE_SHIFT + 1))) + (((1UL << (PAGE_SHIFT + 1)) - 1) << \ + ((sizeof(loff_t) * BITS_PER_BYTE) - (PAGE_SHIFT + 1))) static int hugetlbfs_file_mmap(struct file *file, struct vm_area_struct *vma) { @@ -138,21 +139,32 @@ static int hugetlbfs_file_mmap(struct file *file, struct vm_area_struct *vma) /* * page based offset in vm_pgoff could be sufficiently large to - * overflow a (l)off_t when converted to byte offset. + * overflow a loff_t when converted to byte offset. */ - if (vma->vm_pgoff & PGOFF_LOFFT_MAX) + if ((loff_t)vma->vm_pgoff & (loff_t)PGOFF_LOFFT_MAX) return -EINVAL; - /* must be huge page aligned */ + /* vm_pgoff must be huge page aligned */ if (vma->vm_pgoff & (~huge_page_mask(h) >> PAGE_SHIFT)) return -EINVAL; + /* + * Compute file offset of the end of this mapping + */ vma_len = (loff_t)(vma->vm_end - vma->vm_start); len = vma_len + ((loff_t)vma->vm_pgoff << PAGE_SHIFT); - /* check for overflow */ + + /* Check to ensure this did not overflow loff_t */ if (len < vma_len) return -EINVAL; + /* + * On 32 bit systems, this check is necessary to ensure the last page + * of mapping can be represented as a signed long huge page index. + */ + if ((len >> huge_page_shift(h)) > LONG_MAX) + return -EINVAL; + inode_lock(inode); file_accessed(file); -- 2.13.6