The patch titled
Subject: mm: untag user pointers in mmap/munmap/mremap/brk
has been added to the -mm tree. Its filename is
mm-untag-user-pointers-in-mmap-munmap-mremap-brk.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-untag-user-pointers-in-mmap-munmap-mremap-brk.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-untag-user-pointers-in-mmap-munmap-mremap-brk.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Catalin Marinas <catalin.marinas@xxxxxxx>
Subject: mm: untag user pointers in mmap/munmap/mremap/brk
There isn't a good reason to differentiate between the user address space
layout modification syscalls and the other memory permission/attributes
ones (e.g. mprotect, madvise) w.r.t. the tagged address ABI. Untag the
user addresses on entry to these functions.
Link: http://lkml.kernel.org/r/20190821164730.47450-2-catalin.marinas@xxxxxxx
Signed-off-by: Catalin Marinas <catalin.marinas@xxxxxxx>
Acked-by: Will Deacon <will@xxxxxxxxxx>
Acked-by: Andrey Konovalov <andreyknvl@xxxxxxxxxx>
Cc: Vincenzo Frascino <vincenzo.frascino@xxxxxxx>
Cc: Szabolcs Nagy <szabolcs.nagy@xxxxxxx>
Cc: Kevin Brodsky <kevin.brodsky@xxxxxxx>
Cc: Dave P Martin <Dave.Martin@xxxxxxx>
Cc: Dave Hansen <dave.hansen@xxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
mm/mmap.c | 5 +++++
mm/mremap.c | 6 +-----
2 files changed, 6 insertions(+), 5 deletions(-)
--- a/mm/mmap.c~mm-untag-user-pointers-in-mmap-munmap-mremap-brk
+++ a/mm/mmap.c
@@ -201,6 +201,8 @@ SYSCALL_DEFINE1(brk, unsigned long, brk)
bool downgraded = false;
LIST_HEAD(uf);
+ brk = untagged_addr(brk);
+
if (down_write_killable(&mm->mmap_sem))
return -EINTR;
@@ -1587,6 +1589,8 @@ unsigned long ksys_mmap_pgoff(unsigned l
struct file *file = NULL;
unsigned long retval;
+ addr = untagged_addr(addr);
+
if (!(flags & MAP_ANONYMOUS)) {
audit_mmap_fd(fd, flags);
file = fget(fd);
@@ -2900,6 +2904,7 @@ EXPORT_SYMBOL(vm_munmap);
SYSCALL_DEFINE2(munmap, unsigned long, addr, size_t, len)
{
+ addr = untagged_addr(addr);
profile_munmap(addr);
return __vm_munmap(addr, len, true);
}
--- a/mm/mremap.c~mm-untag-user-pointers-in-mmap-munmap-mremap-brk
+++ a/mm/mremap.c
@@ -606,12 +606,8 @@ SYSCALL_DEFINE5(mremap, unsigned long, a
LIST_HEAD(uf_unmap_early);
LIST_HEAD(uf_unmap);
- /*
- * Architectures may interpret the tag passed to mmap as a background
- * colour for the corresponding vma. For mremap we don't allow tagged
- * new_addr to preserve similar behaviour to mmap.
- */
addr = untagged_addr(addr);
+ new_addr = untagged_addr(new_addr);
if (flags & ~(MREMAP_FIXED | MREMAP_MAYMOVE))
return ret;
_
Patches currently in -mm which might be from catalin.marinas@xxxxxxx are
mm-kmemleak-make-the-tool-tolerant-to-struct-scan_area-allocation-failures.patch
mm-kmemleak-simple-memory-allocation-pool-for-kmemleak-objects.patch
mm-kmemleak-use-the-memory-pool-for-early-allocations.patch
mm-untag-user-pointers-in-mmap-munmap-mremap-brk.patch
