[RFC PATCH] kexec: x86_64: bzImage64: Fix a potential out-of-bound buffer access

[Xunlei Pang]

Currently, there is an out-of-bound memory access in do_bzImage64_load():
    strncpy(modified_cmdline, command_line, COMMAND_LINE_SIZE);

Normally this is ok because the out-of-bound memory usually has already
been allocated, but with the layer of glibc which manages their own heap
allocation and free, in theory it has a chance that this out-of-bound access
will locate at the unmapping vm area and result in SEGV.

In my opinion, we need to avoid such out-of-bound access.

There are also many other places having similar code, this patch is just 
half-baked. If there is no objection, I will make another one handling all.

Signed-off-by: Xunlei Pang <xlpang at redhat.com>
---
 kexec/arch/x86_64/kexec-bzImage64.c | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/kexec/arch/x86_64/kexec-bzImage64.c b/kexec/arch/x86_64/kexec-bzImage64.c
index 8edb3e4..929f7af 100644
--- a/kexec/arch/x86_64/kexec-bzImage64.c
+++ b/kexec/arch/x86_64/kexec-bzImage64.c
@@ -150,11 +150,9 @@ static int do_bzImage64_load(struct kexec_info *info,
 	if (info->kexec_flags & (KEXEC_ON_CRASH | KEXEC_PRESERVE_CONTEXT)) {
 		modified_cmdline = xmalloc(COMMAND_LINE_SIZE);
 		memset((void *)modified_cmdline, 0, COMMAND_LINE_SIZE);
-		if (command_line) {
-			strncpy(modified_cmdline, command_line,
-					COMMAND_LINE_SIZE);
-			modified_cmdline[COMMAND_LINE_SIZE - 1] = '\0';
-		}
+		/* The checking above should gurantee command_line_len's validity. */
+		if (command_line)
+			strncpy(modified_cmdline, command_line, command_line_len);
 
 		/* If panic kernel is being loaded, additional segments need
 		 * to be created. load_crashdump_segments will take care of
@@ -380,6 +378,7 @@ int bzImage64_load(int argc, char **argv, const char *buf, off_t len,
 		command_line = strdup("\0");
 		command_line_len = 1;
 	}
+
 	ramdisk_buf = 0;
 	if (ramdisk)
 		ramdisk_buf = slurp_file(ramdisk, &ramdisk_length);
-- 
2.5.0