lkml.org 
[lkml]   [2014]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] vmcore: prevent PT_NOTE p_memsz overflow during header update
On Sun, Feb 02, 2014 at 02:25:25PM -0800, Eric W. Biederman wrote:
> Andrew Morton <akpm@linux-foundation.org> writes:
>
> > On Sat, 1 Feb 2014 01:07:29 +0000 "Pearson, Greg" <greg.pearson@hp.com> wrote:
> >
> >> As far as I know the only consequence of dropping a PT_NOTE entry is
> >> that it would not be available in the crash dump for use in debugging.
> >> I'm not sure how important this data might be for triage. I'm guessing
> >> that in cases where one of these strange PT_NOTE entries shows up with a
> >> size that causes an overflow it probably isn't even a real PT_NOTE entry
> >> so dropping it won't matter, but that's a guess at this point since I'm
> >> still trying to figure out how the bogus entries were created.
> >
> > Can we detect the crazy-huge notes, skip them and then proceed with
> > the following sanely-sized ones?
>
> The only way we can have following sanely-sized notes is if they are in
> a separate note segment (one of our extensions for kdump and
> /proc/vmcore merges them together).

This processing is happening before we have merged ELF notes. Previous
kernel/kexec-tools prepared per cpu PT_NOTE type ELF note. One for
each cpu. And by default it prepares only one ELF note per PT_NOTE. So
there should not be more notes in the same PT_NOTE.

Also even if there are, n_namesz and n_descsz values seem so high that
after skipping these nothing valid should be after that.

So I will not be too worried about skipping seemingly corrupted ELf
notes. I think giving a warning makes sense though. Is somebody
overwriting the memory area in kenrel reserved for per cpu PT_NOTE.

Thanks
Vivek


\
 
 \ /
  Last update: 2014-02-03 17:21    [W:1.153 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site