diff options
| author | Arthur Zou <zzou@redhat.com> | 2014-03-12 13:05:18 +0800 |
|---|---|---|
| committer | Simon Horman <horms@verge.net.au> | 2014-03-12 14:27:25 +0900 |
| commit | 401e037e5e9527134c594b8923342a69ff38b7cb (patch) | |
| tree | 088ce15755a068e5c92c0cd12e304414d1bf7d15 | |
| parent | ce85138b8a4b3a8655623de063cc55c67b7a9a93 (diff) | |
| download | kexec-tools-401e037e5e9527134c594b8923342a69ff38b7cb.tar.gz | |
vmcore-dmesg stack smashing happend in extreme case
Description
in dump_dmesg_structured() the out_buf size is 4096, and if the
length is less than 4080( 4096-16 ) it won't really write out.
Normally, after writing one or four chars to the out_buf, it will
check the length of out_buf. But in extreme cases, 19 chars was
written to the out_buf before checking the length. This may cause
the stack corruption. If the length was 4079 (won't realy write out),
and then write 19 chars to it. the out_buf will overflow.
Solution
Change 16 to 64 thus can make sure that always have 64bytes before
moving to next records. why using 64 is that a long long int can take
20 bytes. so the length of timestamp can be 44 ('[','.',']',' ') in
extreme case.
Signed-off-by: Arthur Zou <zzou@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
| -rw-r--r-- | vmcore-dmesg/vmcore-dmesg.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/vmcore-dmesg/vmcore-dmesg.c b/vmcore-dmesg/vmcore-dmesg.c index 0345660..e15cd91 100644 --- a/vmcore-dmesg/vmcore-dmesg.c +++ b/vmcore-dmesg/vmcore-dmesg.c @@ -674,7 +674,7 @@ static void dump_dmesg_structured(int fd) else out_buf[len++] = c; - if (len >= OUT_BUF_SIZE - 16) { + if (len >= OUT_BUF_SIZE - 64) { write_to_stdout(out_buf, len); len = 0; } |