[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <e793813c-b2b9-0924-5310-aefb1ab52e48@huawei.com>
Date: Wed, 4 Jan 2023 17:32:30 +0800
From: mawupeng <mawupeng1@...wei.com>
To: <david@...hat.com>, <akpm@...ux-foundation.org>
CC: <mawupeng1@...wei.com>, <linux-mm@...ck.org>,
<linux-kernel@...r.kernel.org>, <kuleshovmail@...il.com>,
<aneesh.kumar@...ux.ibm.com>
Subject: Re: [PATCH 0/4] return EINVAL for illegal user memory range
On 2023/1/2 21:22, David Hildenbrand wrote:
> On 05.12.22 04:41, Wupeng Ma wrote:
>> From: Ma Wupeng <mawupeng1@...wei.com>
>>
>> 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)));
>>
>> However this problem appear in multiple syscalls.
>>
>> Since TASK_SIZE is the maximum user space address. The start or len of
>> mlock shouldn't be bigger than this. Function access_ok can be used to
>> check this issue, so return -EINVAL if bigger.
>
> I assume this makes sure that what we document holds:
>
> EINVAL (mlock(), mlock2(), and munlock()) The result of the addition
> addr+len was less than addr (e.g., the addition may have
> resulted in an overflow).
>
> So instead of adding access_ok() checks, wouldn't be the right think to do checking for overflows?
I agree with you. Do checking only for overflows do seems nice since we need to keep
backward-compatibility.
>
>
Powered by blists - more mailing lists