From 83911ebb61053b3536a7be20793ec76405c23389 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Wed, 2 Oct 2013 10:42:27 +0200 Subject: kexec: Fix off-by-one errors in locate_hole() When calling locate_hole() with "hole_size" equal to the size of an available memory block, it fails to use that memory block. "end" and "hole_max" point to the last byte within the range, hence - "size = end - start" is one less than "hole_size", - "hole_base + hole_size" is one more than "hole_max". Subtract one from "hole_size" when doing the comparison (adding 1 to "size" could overflow in case of one big range covering the whole address space). But explicitly check if "hole_size" is zero first, to handle this case without causing underflows. Signed-off-by: Geert Uytterhoeven Signed-off-by: Simon Horman --- kexec/kexec.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'kexec/kexec.c') diff --git a/kexec/kexec.c b/kexec/kexec.c index b863d2a..2ce570f 100644 --- a/kexec/kexec.c +++ b/kexec/kexec.c @@ -270,7 +270,7 @@ unsigned long locate_hole(struct kexec_info *info, } /* Is there enough space left so we can use it? */ size = end - start; - if (size >= hole_size) { + if (!hole_size || size >= hole_size - 1) { if (hole_end > 0) { hole_base = start; break; @@ -286,7 +286,7 @@ unsigned long locate_hole(struct kexec_info *info, "0x%lx bytes...\n", hole_size); return ULONG_MAX; } - if ((hole_base + hole_size) > hole_max) { + if (hole_size && (hole_base + hole_size - 1) > hole_max) { fprintf(stderr, "Could not find a free area of memory below: " "0x%lx...\n", hole_max); return ULONG_MAX; -- cgit