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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 73745C636D3 for ; Tue, 7 Feb 2023 01:24:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DABD26B0071; Mon, 6 Feb 2023 20:24:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D35146B0073; Mon, 6 Feb 2023 20:24:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BAE8C6B0074; Mon, 6 Feb 2023 20:24:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id A4C8E6B0071 for ; Mon, 6 Feb 2023 20:24:27 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 6E3981A08B7 for ; Tue, 7 Feb 2023 01:24:27 +0000 (UTC) X-FDA: 80438750574.04.B72C0B5 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by imf15.hostedemail.com (Postfix) with ESMTP id 100D2A0002 for ; Tue, 7 Feb 2023 01:24:23 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf15.hostedemail.com: domain of mawupeng1@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=mawupeng1@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675733065; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=f33a2+d/GX72sU6F7Smn6PAqT+PYIP+oBq7Jy/4f4r4=; b=xFCdPQ42ABN0ptX7H2+wH1x2cccKwpAT1AdgL8P5bab3Bg87s7XPQ1gOwyHdNPfAyabFny XLtdPWm5MVLuw/ywE34zww1SHVTli/rmMkvasfRQO/sulCEesnb4LtQNfWv2prEoEV/3LO y3HNHnyZGpL0sPd9xayDbPOTOKyMejw= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf15.hostedemail.com: domain of mawupeng1@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=mawupeng1@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675733065; a=rsa-sha256; cv=none; b=PRRXLdlHAmn+PHAaHf9PjPdykcqLMJo6BLwr27RxMKFa7HrGOELeBciAWb/6ElGaQZsPM8 yTz9pbQK5yxuHIXUJyH9al75SzZmjLGHsVTaWveKV/byHx0AXtmBRNHTNjMxu5r2GtkoLs vpyxLtdkmKJBtT1jv/7FS4EXdixcAag= Received: from dggpemm500014.china.huawei.com (unknown [172.30.72.57]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4P9llS2PttzfYwx; Tue, 7 Feb 2023 09:24:04 +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; Tue, 7 Feb 2023 09:24:19 +0800 Message-ID: Date: Tue, 7 Feb 2023 09:24:19 +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> <10a3929a-7109-169f-6e42-e51c83305567@redhat.com> From: mawupeng In-Reply-To: <10a3929a-7109-169f-6e42-e51c83305567@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.178.120] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To dggpemm500014.china.huawei.com (7.185.36.153) X-CFilter-Loop: Reflected X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 100D2A0002 X-Stat-Signature: 1skiycw3jqhi4rkg11g86w9iopcufhmi X-HE-Tag: 1675733063-681519 X-HE-Meta: U2FsdGVkX1+NrCxFLMaZOfmshDGbc3+i2n4nBOzefuTiagrfYZhJYjvq9tqyXBx3zprQwxpH6nkOZ9WOnXJseOA8l57RZuCRtCUkddhwrtu1GaM0gudb3FzXc0IBrwonaT/yagtXGBlCSfJXdFSxS2ueCMfWzxPg4zUx/OGY/L8SoQqscsUxDMKf4bORNBiSs03D8KWHegJLM6iivmuuVO5xRUkL8Tubhho31NFh1HEdu0YKjdjm0REo7pEHwJtx7ncEptMXgz+frUiZZ0TDR/FHirrSZmUmvxLr+oEibu8MKI6ftkeCo/tOlT+cNrTfAHG8iC7g/n83x1Jbz28ciIexsHTaZo1U3M5xHPvRX534ix8NIQFKqdCgfyHS9FVDt/ofE7I2LK6XZeHzpyNyg0bo8HpX/hfXm1akma3ZVCrlbXGSdm02bRgx0ddAdttqJqXghMm98mT5ivr2dvRo7hnKirxf2k7M4+Ap08LCVHB9klr9Q3GSj85aJ4Jueg+ndKybxozlTyMKof0CnStytorjjBjYOSy/OLz0LU2PlvIv0ynruB2kHWcEcnUB6hbFAl1X4ooKFvWi+RHwO5XzpE2LbR1d3BNI1PtdR/m9tgrVIjJre+4H+bexYyJPWoXpCVfFyRlXrPK9JFHBOjXRz7vZYSpA5N1lDOzqc91CTtR/G8KIiICXxDEQlfjFl+RsOfJs6MzN1QqEEPtqMvbWCHxqYtqjcI0oHkkzGSY8YOpaSQQ8thUWUbhIu/DcsCw0MmdSIQziivA1zoLxJYW7qYBVgqw64UQacQQ4QCVyRsqqABOuhXV8Bf52Cxr9LAhLziakVEDi7sVTh1O+3PtVHiCrctECmtkB1h6uWpBuMtRWmMOlW/szMrZyncmzZAUHWsnJbicgkrNCR1ytocI23rhH4JnHuYve0tNJskxjpH/Ar7x7HZIqwdajGc9CSjq8XXs3HmuQC+aQNnGF23f 9XxFPLaJ yYnd1rFSuXcO0pkMQnZIsX8EvyrM9Zf24rUOXkv9V0y3ecb3WJBYaDcPy90XfX3+Tpb69gbpYa6h9hrSLziiHSGRitxt47bRbUvCHftRnifk9a0bHZaXj1j6oY56+jxDRFS0NVYaevyvXwwMAoi7/V6ZTJg12jKKDLbnI6MRgdZXGAHI= 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 2023/2/7 1:05, David Hildenbrand wrote: > On 06.02.23 01:48, mawupeng wrote: >> >> >> 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(). >> > > I meant the > > end = start + len; > if (end < start) >     return -EINVAL; > > Essentially, what I wanted to double-check is that with your changes, we catch all kinds of overflows as documented in the man page, correct? Oh i see. You are right, The "ordinary" overflows are detected for mlock/munlock in apply_vma_lock_flags(). Yes, we may need to update the man page for all these four syscalls. Thanks, mawupeng. >