Messages in this thread | | | Date | Mon, 3 Feb 2014 10:47:04 -0500 | From | Vivek Goyal <> | Subject | Re: [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
| |