On Wed, Mar 20, 2019 at 03:51:24PM +0100, Andrey Konovalov wrote: > @@ -2120,13 +2135,14 @@ static int prctl_set_mm(int opt, unsigned long addr, > if (opt == PR_SET_MM_AUXV) > return prctl_set_auxv(mm, addr, arg4); > > - if (addr >= TASK_SIZE || addr < mmap_min_addr) > + if (untagged_addr(addr) >= TASK_SIZE || > + untagged_addr(addr) < mmap_min_addr) > return -EINVAL; > > error = -EINVAL; > > down_write(&mm->mmap_sem); > - vma = find_vma(mm, addr); > + vma = find_vma(mm, untagged_addr(addr)); > > prctl_map.start_code = mm->start_code; > prctl_map.end_code = mm->end_code; Does this mean that we are left with tagged addresses for the mm->start_code etc. values? I really don't think we should allow this, I'm not sure what the implications are in other parts of the kernel. Arguably, these are not even pointer values but some address ranges. I know we decided to relax this notion for mmap/mprotect/madvise() since the user function prototypes take pointer as arguments but it feels like we are overdoing it here (struct prctl_mm_map doesn't even have pointers). What is the use-case for allowing tagged addresses here? Can user space handle untagging? -- Catalin
