| Message ID | 20221205034108.3365182-1-mawupeng1@huawei.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | return EINVAL for illegal user memory range | expand |
Hi, maintainers, kindly ping... Thanks. Ma.
On 05.12.22 04:41, Wupeng Ma wrote: > From: Ma Wupeng <mawupeng1@huawei.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?
On 2023/1/2 21:22, David Hildenbrand wrote: > On 05.12.22 04:41, Wupeng Ma wrote: >> From: Ma Wupeng <mawupeng1@huawei.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. > >
From: Ma Wupeng <mawupeng1@huawei.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. Ma Wupeng (4): mm/mlock: return EINVAL for illegal user memory range in mlock mm/mempolicy: return EINVAL for illegal user memory range for set_mempolicy_home_node mm/mempolicy: return EINVAL for illegal user memory range for mbind mm/msync: return EINVAL for illegal user memory range for msync mm/mempolicy.c | 7 +++++++ mm/mlock.c | 6 ++++++ mm/msync.c | 2 ++ 3 files changed, 15 insertions(+)