2.6.27.59-stable review patch. If anyone has any objections, please let us know.
------------------ From: Linus Torvalds <[email protected]> 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 <[email protected]> Acked-by: Hugh Dickins <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> [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; _______________________________________________ stable mailing list [email protected] http://linux.kernel.org/mailman/listinfo/stable
