From: Andrew Morton <akpm@linux-foundation.org>
To: "Pearson, Greg" <greg.pearson@hp.com>
Cc: "vgoyal@redhat.com" <vgoyal@redhat.com>,
"d.hatayama@jp.fujitsu.com" <d.hatayama@jp.fujitsu.com>,
"holzheu@linux.vnet.ibm.com" <holzheu@linux.vnet.ibm.com>,
"dhowells@redhat.com" <dhowells@redhat.com>,
"paul.gortmaker@windriver.com" <paul.gortmaker@windriver.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] vmcore: prevent PT_NOTE p_memsz overflow during header update
Date: Fri, 31 Jan 2014 18:12:54 -0800 [thread overview]
Message-ID: <20140131181254.da3f8e97.akpm@linux-foundation.org> (raw)
In-Reply-To: <52EC48D0.4000503@hp.com>
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?
next prev parent reply other threads:[~2014-02-01 2:08 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-31 23:06 [PATCH] vmcore: prevent PT_NOTE p_memsz overflow during header update Greg Pearson
2014-01-31 23:14 ` Andrew Morton
2014-01-31 23:16 ` Andrew Morton
2014-02-01 1:07 ` Pearson, Greg
2014-02-01 2:12 ` Andrew Morton [this message]
2014-02-02 22:25 ` Eric W. Biederman
2014-02-03 15:47 ` Vivek Goyal
2014-02-03 16:57 ` Pearson, Greg
2014-02-03 17:05 ` Vivek Goyal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140131181254.da3f8e97.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=d.hatayama@jp.fujitsu.com \
--cc=dhowells@redhat.com \
--cc=greg.pearson@hp.com \
--cc=holzheu@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paul.gortmaker@windriver.com \
--cc=vgoyal@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.