[PATCH 131/173] mm: avoid wrapping vm_pgoff in mremap()
From: Willy Tarreau
Date: Mon Apr 25 2011 - 16:32:33 EST
2.6.27.59-stable review patch. If anyone has any objections, please let us know.
------------------
From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
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@xxxxxxxxxxx>
Acked-by: Hugh Dickins <hughd@xxxxxxxxxx>
Signed-off-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxx>
[wt: 2.6.27 has this code in do_mremap()]
---
mm/mremap.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
Index: longterm-2.6.27/mm/mremap.c
===================================================================
--- longterm-2.6.27.orig/mm/mremap.c 2011-04-25 15:24:54.000000000 +0200
+++ longterm-2.6.27/mm/mremap.c 2011-04-25 17:01:30.075279051 +0200
@@ -333,10 +333,21 @@
/* We can't remap across vm area boundaries */
if (old_len > vma->vm_end - addr)
goto out;
- 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 out;
+ pgoff = (addr - vma->vm_start) >> PAGE_SHIFT;
+ pgoff += vma->vm_pgoff;
+ if (pgoff + (new_len >> PAGE_SHIFT) < pgoff) {
+ ret = -EINVAL;
goto out;
+ }
}
+
if (vma->vm_flags & VM_LOCKED) {
unsigned long locked, lock_limit;
locked = mm->locked_vm << PAGE_SHIFT;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/