From: Shiraz Hashim <shashim@xxxxxxxxxxxxxx> Subject: 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@xxxxxxxxxxxxxx Signed-off-by: Shiraz Hashim <shashim@xxxxxxxxxxxxxx> Cc: Catalin Marinas <catalin.marinas@xxxxxxx> Cc: Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> --- mm/cma.c | 3 +++ 1 file changed, 3 insertions(+) diff -puN mm/cma.c~mm-cma-check-the-max-limit-for-cma-allocation mm/cma.c --- a/mm/cma.c~mm-cma-check-the-max-limit-for-cma-allocation +++ a/mm/cma.c @@ -385,6 +385,9 @@ struct page *cma_alloc(struct cma *cma, 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, _ -- To unsubscribe from this list: send the line "unsubscribe mm-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
