summaryrefslogtreecommitdiff
path: root/mm/mremap.c
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2011-04-07 07:35:50 -0700
committerPaul Gortmaker <paul.gortmaker@windriver.com>2012-03-14 10:57:01 -0400
commitab3d0ed0ae191a15cbc3a955e9b80d7b1f2b627a (patch)
tree0af204df72b2e49badb2c7aa150b92f68d014251 /mm/mremap.c
parent81ddfae08a9d9e52be260ee755891f9861bd26c2 (diff)
mm: avoid wrapping vm_pgoff in mremap()
commit 982134ba62618c2d69fbbbd166d0a11ee3b7e3d8 upstream. 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> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Diffstat (limited to 'mm/mremap.c')
-rw-r--r--mm/mremap.c11
1 files changed, 9 insertions, 2 deletions
diff --git a/mm/mremap.c b/mm/mremap.c
index 10d5f6264514..97de5aef9431 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -274,9 +274,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) {