aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorShiraz Hashim <shashim@codeaurora.org>2016-11-10 10:46:16 -0800
committerLinus Torvalds <torvalds@linux-foundation.org>2016-11-11 08:12:37 -0800
commit6b36ba599d602d8a73920fb5c470fe272fac49c1 (patch)
tree013d0a9d0eb45539fe656545edcfded22e2ee37f
parenteef06b82f16c78dc0197e3e9d5b2230647a890ff (diff)
downloadlinux-fpga-6b36ba599d602d8a73920fb5c470fe272fac49c1.tar.gz
mm/cma.c: check the max limit for cma allocation
CMA allocation request size is represented by size_t that gets truncated when same is passed as int to bitmap_find_next_zero_area_off. We observe that during fuzz testing when cma allocation request is too high, bitmap_find_next_zero_area_off still returns success due to the truncation. This leads to kernel crash, as subsequent code assumes that requested memory is available. Fail cma allocation in case the request breaches the corresponding cma region size. Link: http://lkml.kernel.org/r/1478189211-3467-1-git-send-email-shashim@codeaurora.org Signed-off-by: Shiraz Hashim <shashim@codeaurora.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-rw-r--r--mm/cma.c3
1 files changed, 3 insertions, 0 deletions
diff --git a/mm/cma.c b/mm/cma.c
index 384c2cb51b56bf..c960459eda7e64 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -385,6 +385,9 @@ struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align)
bitmap_maxno = cma_bitmap_maxno(cma);
bitmap_count = cma_bitmap_pages_to_bits(cma, count);
+ if (bitmap_count > bitmap_maxno)
+ return NULL;
+
for (;;) {
mutex_lock(&cma->lock);
bitmap_no = bitmap_find_next_zero_area_off(cma->bitmap,