mirror of
https://github.com/joel16/android_kernel_sony_msm8994_rework.git
synced 2024-11-30 07:10:45 +00:00
mm: avoid wrapping vm_pgoff in mremap()
The normal mmap paths all avoid creating a mapping where the pgoff inside the mapping could wrap around due to overflow. However, an expanding mremap() can take such a non-wrapping mapping and make it bigger and cause a wrapping condition. Noticed by Robert Swiecki when running a system call fuzzer, where it caused a BUG_ON() due to terminally confusing the vma_prio_tree code. A vma dumping patch by Hugh then pinpointed the crazy wrapped case. Reported-and-tested-by: Robert Swiecki <robert@swiecki.net> Acked-by: Hugh Dickins <hughd@google.com> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This commit is contained in:
parent
6221f222c0
commit
982134ba62
11
mm/mremap.c
11
mm/mremap.c
@ -277,9 +277,16 @@ static struct vm_area_struct *vma_to_resize(unsigned long addr,
|
||||
if (old_len > vma->vm_end - addr)
|
||||
goto Efault;
|
||||
|
||||
if (vma->vm_flags & (VM_DONTEXPAND | VM_PFNMAP)) {
|
||||
if (new_len > old_len)
|
||||
/* Need to be careful about a growing mapping */
|
||||
if (new_len > old_len) {
|
||||
unsigned long pgoff;
|
||||
|
||||
if (vma->vm_flags & (VM_DONTEXPAND | VM_PFNMAP))
|
||||
goto Efault;
|
||||
pgoff = (addr - vma->vm_start) >> PAGE_SHIFT;
|
||||
pgoff += vma->vm_pgoff;
|
||||
if (pgoff + (new_len >> PAGE_SHIFT) < pgoff)
|
||||
goto Einval;
|
||||
}
|
||||
|
||||
if (vma->vm_flags & VM_LOCKED) {
|
||||
|
Loading…
Reference in New Issue
Block a user