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
