From: Sean Christopherson <sean.j.christopherson@intel.com>
To: lkp@lists.01.org
Subject: Re: 4ce5f9c9e7 [ 1.323881] WARNING: CPU: 0 PID: 1 at mm/slab_common.c:1031 kmalloc_slab
Date: Wed, 10 Oct 2018 17:31:42 -0700 [thread overview]
Message-ID: <20181011003141.GA25974@linux.intel.com> (raw)
In-Reply-To: <20181010234148.GA25537@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 2505 bytes --]
On Wed, Oct 10, 2018 at 04:41:48PM -0700, Sean Christopherson wrote:
> On Wed, Oct 10, 2018 at 05:06:52PM -0500, Eric W. Biederman wrote:
> > ebiederm(a)xmission.com (Eric W. Biederman) writes:
> >
> > > So I am flummoxed. I am reading through the code and I don't see
> > > anything that could trigger this, and when I ran the supplied reproducer
> > > it did not reproduce for me.
> >
> > Even more so. With my tool chain the line that reports the failing
> > address is impossible.
> >
> > [ 73.034423] RIP: 0010:copy_siginfo_from_user+0x4d/0xd0
> >
> > With the supplied configureation my tool chain only has 0x30 bytes for
> > all of copy_siginfo_from_user. So I can't even begin to guess where
> > in that function things are failing.
> >
> > Any additional information that you can provide would be a real help
> > in tracking down this strange failure.
>
> I don't have the exact toolchain, but I was able to get somewhat close
> and may have found a smoking gun. 0x4d in my build is in the general
> vicinity of "sig_sicodes[sig].limit" in known_siginfo_layout(). This
> lines up with the register state from the log, e.g. RDI=0500104d8,
> which is the mask generated by sig_specific_sicodes. From what I can
> tell, @sig is never bounds checked. If the compiler generated an AND
> instruction to compare against sig_specific_sicodes then that could
> resolve true with any arbitrary value that happened to collide with
> sig_specific_sicodes and result in an out-of-bounds access to
> @sig_sicodes. siginfo_layout() for example explicitly checks @sig
> before indexing @sig_sicode, e.g. "sig < ARRAY_SIZE(sig_sicodes)".
Hmm, siginmask explicitly checks sig < SIGRTMIN, which might squash
my theory.
>
> Maybe this?
>
> ---
> kernel/signal.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/signal.c b/kernel/signal.c
> index 1c2dd117fee0..6ee7491de906 100644
> --- a/kernel/signal.c
> +++ b/kernel/signal.c
> @@ -2865,7 +2865,8 @@ static bool known_siginfo_layout(int sig, int si_code)
> if (si_code == SI_KERNEL)
> return true;
> else if ((si_code > SI_USER)) {
> - if (sig_specific_sicodes(sig)) {
> + if (sig < ARRAY_SIZE(sig_sicodes) &&
> + sig_specific_sicodes(sig)) {
> if (si_code <= sig_sicodes[sig].limit)
> return true;
> }
WARNING: multiple messages have this Message-ID (diff)
From: Sean Christopherson <sean.j.christopherson@intel.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: kernel test robot <rong.a.chen@intel.com>,
linux-kernel@vger.kernel.org, LKP <lkp@01.org>
Subject: Re: [LKP] 4ce5f9c9e7 [ 1.323881] WARNING: CPU: 0 PID: 1 at mm/slab_common.c:1031 kmalloc_slab
Date: Wed, 10 Oct 2018 17:31:42 -0700 [thread overview]
Message-ID: <20181011003141.GA25974@linux.intel.com> (raw)
In-Reply-To: <20181010234148.GA25537@linux.intel.com>
On Wed, Oct 10, 2018 at 04:41:48PM -0700, Sean Christopherson wrote:
> On Wed, Oct 10, 2018 at 05:06:52PM -0500, Eric W. Biederman wrote:
> > ebiederm@xmission.com (Eric W. Biederman) writes:
> >
> > > So I am flummoxed. I am reading through the code and I don't see
> > > anything that could trigger this, and when I ran the supplied reproducer
> > > it did not reproduce for me.
> >
> > Even more so. With my tool chain the line that reports the failing
> > address is impossible.
> >
> > [ 73.034423] RIP: 0010:copy_siginfo_from_user+0x4d/0xd0
> >
> > With the supplied configureation my tool chain only has 0x30 bytes for
> > all of copy_siginfo_from_user. So I can't even begin to guess where
> > in that function things are failing.
> >
> > Any additional information that you can provide would be a real help
> > in tracking down this strange failure.
>
> I don't have the exact toolchain, but I was able to get somewhat close
> and may have found a smoking gun. 0x4d in my build is in the general
> vicinity of "sig_sicodes[sig].limit" in known_siginfo_layout(). This
> lines up with the register state from the log, e.g. RDI=0500104d8,
> which is the mask generated by sig_specific_sicodes. From what I can
> tell, @sig is never bounds checked. If the compiler generated an AND
> instruction to compare against sig_specific_sicodes then that could
> resolve true with any arbitrary value that happened to collide with
> sig_specific_sicodes and result in an out-of-bounds access to
> @sig_sicodes. siginfo_layout() for example explicitly checks @sig
> before indexing @sig_sicode, e.g. "sig < ARRAY_SIZE(sig_sicodes)".
Hmm, siginmask explicitly checks sig < SIGRTMIN, which might squash
my theory.
>
> Maybe this?
>
> ---
> kernel/signal.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/signal.c b/kernel/signal.c
> index 1c2dd117fee0..6ee7491de906 100644
> --- a/kernel/signal.c
> +++ b/kernel/signal.c
> @@ -2865,7 +2865,8 @@ static bool known_siginfo_layout(int sig, int si_code)
> if (si_code == SI_KERNEL)
> return true;
> else if ((si_code > SI_USER)) {
> - if (sig_specific_sicodes(sig)) {
> + if (sig < ARRAY_SIZE(sig_sicodes) &&
> + sig_specific_sicodes(sig)) {
> if (si_code <= sig_sicodes[sig].limit)
> return true;
> }
next prev parent reply other threads:[~2018-10-11 0:31 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-10 2:06 4ce5f9c9e7 [ 1.323881] WARNING: CPU: 0 PID: 1 at mm/slab_common.c:1031 kmalloc_slab kernel test robot
2018-10-10 2:06 ` [LKP] " kernel test robot
2018-10-10 15:43 ` Eric W. Biederman
2018-10-10 15:43 ` [LKP] " Eric W. Biederman
2018-10-10 22:06 ` Eric W. Biederman
2018-10-10 22:06 ` [LKP] " Eric W. Biederman
2018-10-10 23:41 ` Sean Christopherson
2018-10-10 23:41 ` [LKP] " Sean Christopherson
2018-10-11 0:31 ` Sean Christopherson [this message]
2018-10-11 0:31 ` Sean Christopherson
2018-10-11 1:11 ` Eric W. Biederman
2018-10-11 1:11 ` [LKP] " Eric W. Biederman
2018-10-11 1:14 ` Eric W. Biederman
2018-10-11 1:14 ` [LKP] " Eric W. Biederman
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=20181011003141.GA25974@linux.intel.com \
--to=sean.j.christopherson@intel.com \
--cc=lkp@lists.01.org \
/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.