Message ID | 20230306113317.2295343-1-mawupeng1@huawei.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp1787185wrd; Mon, 6 Mar 2023 03:40:32 -0800 (PST) X-Google-Smtp-Source: AK7set+vy5QKpG+MrF87xCjMggSqmxPtzhRfji44uPrtaTeLavEg3pwE6GLScLP1aMOZcnha4ezj X-Received: by 2002:a17:907:6e25:b0:878:54e3:e3e1 with SMTP id sd37-20020a1709076e2500b0087854e3e3e1mr13234201ejc.73.1678102832141; Mon, 06 Mar 2023 03:40:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1678102832; cv=none; d=google.com; s=arc-20160816; b=a6t5efqWKcGgt1zceSYmLKviFe0yW1ksUH+U85iaD1BgXfjRGq3PZEVmCzP5XU1z55 91l0oP0c+zohI7v0G82t0vf1V7B1cpFeYRbe0yBGgvewMQvySzL2MczS1pvVHILjNpa/ zRKg75tNBpJw8Ix0zV/Kn+KoM1LTAqtPREFs2g56+B7dhU/koNw1bTkcts/NRTx6qSIk 0CyOB10eyaSyzeSfgy2qNxagr7CNowd2gCycekUYCiFbVf2y+z2LIkdSqxxL7SR+8Tmk SJr0r7060tchOOV/LvYfHgbZSecWsZ0Vae5wp+WFeb9MeVJYt44jDxGRu0btobTDRKzI fHIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=Jp/umWUqzoHIcv0LfjOfOD/fmfXlTALX/82dBZbFAbY=; b=WTiY02MMp0qxE3m5uLaFLgRelVdXyEpfMVkN64U66coyxB1oSqH0w/fX+UPBeRBWG1 2HjYFpDCiH5NYyHmypOAZnHcGrOCJ1N8Ik4YBvmUtiGhAvqNH6A2ZMO4M8r1UfY3SidJ 7JvRvkx8QkNFPNslrgbNOARQSLNz8Uwato/My8nWJw4j61QAt7OmgjrfZ/GSy9lUsfew mmIu38vCw7QtKpB1sfulqJ0iq20r35qcPZ+99LfYTA5XDn8Lg2/c0BRHPSTkAXjCeeNU 06XblY1feUGFvvsEHfe0eSdJsTiIJ0UFO/eS1b0pfbZrTH9eemQ2hO8VBH0kTv1Yt2Yg uMuw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s5-20020aa7d785000000b004cebb5c1590si5131123edq.446.2023.03.06.03.40.08; Mon, 06 Mar 2023 03:40:32 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229871AbjCFLdq (ORCPT <rfc822;toshivichauhan@gmail.com> + 99 others); Mon, 6 Mar 2023 06:33:46 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49720 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229901AbjCFLdl (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 6 Mar 2023 06:33:41 -0500 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5FF435593; Mon, 6 Mar 2023 03:33:29 -0800 (PST) Received: from dggpemm500014.china.huawei.com (unknown [172.30.72.55]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4PVbxg06k5zKq0x; Mon, 6 Mar 2023 19:31:19 +0800 (CST) Received: from localhost.localdomain (10.175.112.125) by dggpemm500014.china.huawei.com (7.185.36.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.21; Mon, 6 Mar 2023 19:33:21 +0800 From: Wupeng Ma <mawupeng1@huawei.com> To: <akpm@linux-foundation.org>, <willy@infradead.org> CC: <linux-fsdevel@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>, <mawupeng1@huawei.com> Subject: [PATCH] mm: Return early in truncate_pagecache if newsize overflows Date: Mon, 6 Mar 2023 19:33:17 +0800 Message-ID: <20230306113317.2295343-1-mawupeng1@huawei.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.175.112.125] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To dggpemm500014.china.huawei.com (7.185.36.153) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1759618354857951544?= X-GMAIL-MSGID: =?utf-8?q?1759618354857951544?= |
Series |
mm: Return early in truncate_pagecache if newsize overflows
|
|
Commit Message
mawupeng
March 6, 2023, 11:33 a.m. UTC
From: Ma Wupeng <mawupeng1@huawei.com> Our own test reports a UBSAN in truncate_pagecache: UBSAN: Undefined behaviour in mm/truncate.c:788:9 signed integer overflow: 9223372036854775807 + 1 cannot be represented in type 'long long int' Call Trace: truncate_pagecache+0xd4/0xe0 truncate_setsize+0x70/0x88 simple_setattr+0xdc/0x100 notify_change+0x654/0xb00 do_truncate+0x108/0x1a8 do_sys_ftruncate+0x2ec/0x4a0 __arm64_sys_ftruncate+0x5c/0x80 For huge file which pass LONG_MAX to ftruncate, truncate_pagecache() will be called to truncate with newsize be LONG_MAX which will lead to overflow for holebegin: loff_t holebegin = round_up(newsize, PAGE_SIZE); Since there is no meaning to truncate a file to LONG_MAX, return here to avoid burn a bunch of cpu cycles. Signed-off-by: Ma Wupeng <mawupeng1@huawei.com> --- mm/truncate.c | 3 +++ 1 file changed, 3 insertions(+)
Comments
Hi maintainers. Kindly ping. On 2023/3/6 19:33, Wupeng Ma wrote: > From: Ma Wupeng <mawupeng1@huawei.com> > > Our own test reports a UBSAN in truncate_pagecache: > > UBSAN: Undefined behaviour in mm/truncate.c:788:9 > signed integer overflow: > 9223372036854775807 + 1 cannot be represented in type 'long long int' > > Call Trace: > truncate_pagecache+0xd4/0xe0 > truncate_setsize+0x70/0x88 > simple_setattr+0xdc/0x100 > notify_change+0x654/0xb00 > do_truncate+0x108/0x1a8 > do_sys_ftruncate+0x2ec/0x4a0 > __arm64_sys_ftruncate+0x5c/0x80 > > For huge file which pass LONG_MAX to ftruncate, truncate_pagecache() will > be called to truncate with newsize be LONG_MAX which will lead to > overflow for holebegin: > > loff_t holebegin = round_up(newsize, PAGE_SIZE); > > Since there is no meaning to truncate a file to LONG_MAX, return here > to avoid burn a bunch of cpu cycles. > > Signed-off-by: Ma Wupeng <mawupeng1@huawei.com> > --- > mm/truncate.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/mm/truncate.c b/mm/truncate.c > index 7b4ea4c4a46b..99b6ce2d669b 100644 > --- a/mm/truncate.c > +++ b/mm/truncate.c > @@ -730,6 +730,9 @@ void truncate_pagecache(struct inode *inode, loff_t newsize) > struct address_space *mapping = inode->i_mapping; > loff_t holebegin = round_up(newsize, PAGE_SIZE); > > + if (holebegin < 0) > + return; > + > /* > * unmap_mapping_range is called twice, first simply for > * efficiency so that truncate_inode_pages does fewer
On Mon, 6 Mar 2023 19:33:17 +0800 Wupeng Ma <mawupeng1@huawei.com> wrote: > From: Ma Wupeng <mawupeng1@huawei.com> > > Our own test reports a UBSAN in truncate_pagecache: > > UBSAN: Undefined behaviour in mm/truncate.c:788:9 > signed integer overflow: > 9223372036854775807 + 1 cannot be represented in type 'long long int' > > Call Trace: > truncate_pagecache+0xd4/0xe0 > truncate_setsize+0x70/0x88 > simple_setattr+0xdc/0x100 > notify_change+0x654/0xb00 > do_truncate+0x108/0x1a8 > do_sys_ftruncate+0x2ec/0x4a0 > __arm64_sys_ftruncate+0x5c/0x80 > > For huge file which pass LONG_MAX to ftruncate, truncate_pagecache() will > be called to truncate with newsize be LONG_MAX which will lead to > overflow for holebegin: > > loff_t holebegin = round_up(newsize, PAGE_SIZE); > > Since there is no meaning to truncate a file to LONG_MAX, return here > to avoid burn a bunch of cpu cycles. > > ... > > --- a/mm/truncate.c > +++ b/mm/truncate.c > @@ -730,6 +730,9 @@ void truncate_pagecache(struct inode *inode, loff_t newsize) > struct address_space *mapping = inode->i_mapping; > loff_t holebegin = round_up(newsize, PAGE_SIZE); > > + if (holebegin < 0) > + return; > + It's awkward to perform an operation which might experience overflow and to then test the possibly-overflowed result! In fact it might still generate the UBSAN warning, depending on what the compiler decides to do with it all. So wouldn't it be better to check the input argument *before* performing these operations on it? Preferably with a code comment which explains the reason for the check, please.
diff --git a/mm/truncate.c b/mm/truncate.c index 7b4ea4c4a46b..99b6ce2d669b 100644 --- a/mm/truncate.c +++ b/mm/truncate.c @@ -730,6 +730,9 @@ void truncate_pagecache(struct inode *inode, loff_t newsize) struct address_space *mapping = inode->i_mapping; loff_t holebegin = round_up(newsize, PAGE_SIZE); + if (holebegin < 0) + return; + /* * unmap_mapping_range is called twice, first simply for * efficiency so that truncate_inode_pages does fewer