BugLink: http://bugs.launchpad.net/bugs/869243
CVE-2011-2496

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>
(cherry picked from commit 982134ba62618c2d69fbbbd166d0a11ee3b7e3d8)

Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
---
mm/mremap.c | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/mm/mremap.c b/mm/mremap.c
index f61efb2..eefaeab 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -255,9 +255,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) {
--
1.7.1


--------------070807070704070205020206
Content-Type: text/x-patch;
name="0002-vm-fix-vm_pgoff-wrap-in-stack-expansion-CVE-2011-249.patch"
Content-Disposition: attachment;
filename*0="0002-vm-fix-vm_pgoff-wrap-in-stack-expansion-CVE-2011-249.pa";
filename*1="tch"
Content-Transfer-Encoding: quoted-printable