aboutsummaryrefslogtreecommitdiffstats
path: root/mm/vmalloc.c
diff options
context:
space:
mode:
authorRobert Bragg <robert@sixbynine.org>2008-02-05 01:29:18 -0500
committerLinus Torvalds <torvalds@woody.linux-foundation.org>2008-02-05 12:44:18 -0500
commit5dc331852848a38ca00a2817e5b98a1d0561b116 (patch)
treec306874d0194ecf88c2073a042e6f932e710f67f /mm/vmalloc.c
parenta7f75e25860ac0a7b70cf6e14c37618d2d2bb890 (diff)
mm: don't allow ioremapping of ranges larger than vmalloc space
When running with a 16M IOREMAP_MAX_ORDER (on armv7) we found that the vmlist search routine in __get_vm_area_node can mistakenly allow a driver to ioremap a range larger than vmalloc space. If at the time of the ioremap all existing vmlist areas sit below the determined alignment then the search routine continues past all entries and exits the for loop - straight into the found: label - without ever testing for integer wrapping or that the requested size fits. We were seeing a driver successfully ioremap 128M of flash even though there was only 120M of vmalloc space. From that point the system was left with the remainder of the first 16M of space to vmalloc/ioremap within. Signed-off-by: Robert Bragg <robert@sixbynine.org> Acked-by: Nick Piggin <npiggin@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'mm/vmalloc.c')
-rw-r--r--mm/vmalloc.c4
1 files changed, 4 insertions, 0 deletions
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 4efc41a6e2ab..0536dde139d1 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -254,6 +254,10 @@ static struct vm_struct *__get_vm_area_node(unsigned long size, unsigned long fl
254 if (addr > end - size) 254 if (addr > end - size)
255 goto out; 255 goto out;
256 } 256 }
257 if ((size + addr) < addr)
258 goto out;
259 if (addr > end - size)
260 goto out;
257 261
258found: 262found:
259 area->next = *p; 263 area->next = *p;