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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CDF50C636CD for ; Mon, 6 Feb 2023 00:48:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229496AbjBFAsM (ORCPT ); Sun, 5 Feb 2023 19:48:12 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50624 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229448AbjBFAsK (ORCPT ); Sun, 5 Feb 2023 19:48:10 -0500 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 785D31207B for ; Sun, 5 Feb 2023 16:48:08 -0800 (PST) Received: from dggpemm500014.china.huawei.com (unknown [172.30.72.57]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4P96yV4DtZzJsG5; Mon, 6 Feb 2023 08:46:26 +0800 (CST) Received: from [10.174.178.120] (10.174.178.120) 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.2375.34; Mon, 6 Feb 2023 08:48:05 +0800 Message-ID: Date: Mon, 6 Feb 2023 08:48:05 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.7.0 CC: , , , , Subject: Re: [PATCH v3 1/4] mm/mlock: return EINVAL if len overflows for mlock/munlock Content-Language: en-US To: , References: <20230128063229.989058-1-mawupeng1@huawei.com> <20230128063229.989058-2-mawupeng1@huawei.com> <753c53d3-84a6-da73-4121-0db4a71e4fde@redhat.com> From: mawupeng In-Reply-To: <753c53d3-84a6-da73-4121-0db4a71e4fde@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.178.120] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To dggpemm500014.china.huawei.com (7.185.36.153) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2023/2/4 1:14, David Hildenbrand wrote: > On 28.01.23 07:32, Wupeng Ma wrote: >> From: Ma Wupeng >> >> While testing mlock, we have a problem if the len of mlock is ULONG_MAX. >> The return value of mlock is zero. But nothing will be locked since the >> len in do_mlock overflows to zero due to the following code in mlock: >> >>    len = PAGE_ALIGN(len + (offset_in_page(start))); >> >> The same problem happens in munlock. >> >> Add new check and return -EINVAL to fix this overflowing scenarios since >> they are absolutely wrong. >> >> Return 0 early to avoid burn a bunch of cpu cycles if len == 0. >> >> Signed-off-by: Ma Wupeng >> --- >>   mm/mlock.c | 14 ++++++++++++-- >>   1 file changed, 12 insertions(+), 2 deletions(-) >> >> diff --git a/mm/mlock.c b/mm/mlock.c >> index 7032f6dd0ce1..eb09968ba27f 100644 >> --- a/mm/mlock.c >> +++ b/mm/mlock.c >> @@ -478,8 +478,6 @@ static int apply_vma_lock_flags(unsigned long start, size_t len, >>       end = start + len; >>       if (end < start) >>           return -EINVAL; >> -    if (end == start) >> -        return 0; >>       vma = mas_walk(&mas); >>       if (!vma) >>           return -ENOMEM; >> @@ -575,7 +573,13 @@ static __must_check int do_mlock(unsigned long start, size_t len, vm_flags_t fla >>       if (!can_do_mlock()) >>           return -EPERM; >>   +    if (!len) >> +        return 0; >> + >>       len = PAGE_ALIGN(len + (offset_in_page(start))); >> +    if (!len) >> +        return -EINVAL; >> + >>       start &= PAGE_MASK; > > The "ordinary" overflows are detected in apply_vma_lock_flags(), correct? Overflow is not checked anywhere however the ordinary return early if len == 0 is detected in apply_vma_lock_flags(). do_mlock apply_vma_lock_flags end = start + len; if (end == start) return 0; Move the checking to the begin is easier to detect overflows and make the logic clearer and avoid burn a bunch of cpu cycles. >