All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ondrej Mosnacek <omosnace@redhat.com>
To: Paul Moore <paul@paul-moore.com>
Cc: Casey Schaufler <casey@schaufler-ca.com>,
	LKML <linux-kernel@vger.kernel.org>,
	selinux@vger.kernel.org, lkp@01.org,
	kernel test robot <rong.a.chen@intel.com>,
	Tejun Heo <tj@kernel.org>
Subject: Re: [kernfs] e19dfdc83b: BUG:KASAN:global-out-of-bounds_in_s
Date: Tue, 26 Mar 2019 13:33:54 +0100	[thread overview]
Message-ID: <CAFqZXNtazgAzoFDMiQWOdaVNcpAH3PEEXwwJ8D+njGoEX4+DvA@mail.gmail.com> (raw)
In-Reply-To: <CAFqZXNuJMJTjGL5qGoemy4O--Y3kGGwGb2TfwJ5xxFAz03uPqg@mail.gmail.com>

On Mon, Mar 25, 2019 at 6:06 PM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> On Mon, Mar 25, 2019 at 4:17 PM Paul Moore <paul@paul-moore.com> wrote:
> > Ondrej, please look into this.
> >
> > You've looked at this code more recently than I have, but it looks
> > like there might be an issue with __kernfs_iattrs() returning a
> > pointer to a kernfs_iattrs object without taking a kernfs reference
> > (kernfs_get(kn)).  Although I would be a little surprised if this was
> > the problem as I think it would cause a number of issues beyond just
> > this one ... ?
>
> I think this is actually because of how xattr_full_name() reconstructs
> the full name from the xattr suffix. It assumes that the suffix was
> obtained from the full name by just taking a pointer inside it, but in
> kernfs_security_xattr_get/set() I pass the suffix directly... I'm
> surprised that this didn't fail spectacularly earlier during testing.
> Maybe the newer GCC does some clever merging of the string constants,
> so that XATTR_SELINUX_SUFFIX actually ends up as a substring of
> XATTR_NAME_SELINUX? (That would be one hell of a "lucky" coincidence
> :)
>
> I'll post a patch that converts kernfs_security_xattr_get/set() to
> take the full name and hopefully that will fix the problem. I'll see
> if I can run the reproducer locally tomorrow...

I managed to reproduce the KASAN warning in my kernel testing
environment by simply enabling CONFIG_KASAN and running the cgroupfs
issue reproducer from the original patchset. With the patch I posted I
no longer get the warning, so I believe it really fixes the problem.

--
Ondrej Mosnacek <omosnace at redhat dot com>
Software Engineer, Security Technologies
Red Hat, Inc.

WARNING: multiple messages have this Message-ID (diff)
From: Ondrej Mosnacek <omosnace@redhat.com>
To: lkp@lists.01.org
Subject: Re: [kernfs] e19dfdc83b: BUG:KASAN:global-out-of-bounds_in_s
Date: Tue, 26 Mar 2019 13:33:54 +0100	[thread overview]
Message-ID: <CAFqZXNtazgAzoFDMiQWOdaVNcpAH3PEEXwwJ8D+njGoEX4+DvA@mail.gmail.com> (raw)
In-Reply-To: <CAFqZXNuJMJTjGL5qGoemy4O--Y3kGGwGb2TfwJ5xxFAz03uPqg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1738 bytes --]

On Mon, Mar 25, 2019 at 6:06 PM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> On Mon, Mar 25, 2019 at 4:17 PM Paul Moore <paul@paul-moore.com> wrote:
> > Ondrej, please look into this.
> >
> > You've looked at this code more recently than I have, but it looks
> > like there might be an issue with __kernfs_iattrs() returning a
> > pointer to a kernfs_iattrs object without taking a kernfs reference
> > (kernfs_get(kn)).  Although I would be a little surprised if this was
> > the problem as I think it would cause a number of issues beyond just
> > this one ... ?
>
> I think this is actually because of how xattr_full_name() reconstructs
> the full name from the xattr suffix. It assumes that the suffix was
> obtained from the full name by just taking a pointer inside it, but in
> kernfs_security_xattr_get/set() I pass the suffix directly... I'm
> surprised that this didn't fail spectacularly earlier during testing.
> Maybe the newer GCC does some clever merging of the string constants,
> so that XATTR_SELINUX_SUFFIX actually ends up as a substring of
> XATTR_NAME_SELINUX? (That would be one hell of a "lucky" coincidence
> :)
>
> I'll post a patch that converts kernfs_security_xattr_get/set() to
> take the full name and hopefully that will fix the problem. I'll see
> if I can run the reproducer locally tomorrow...

I managed to reproduce the KASAN warning in my kernel testing
environment by simply enabling CONFIG_KASAN and running the cgroupfs
issue reproducer from the original patchset. With the patch I posted I
no longer get the warning, so I believe it really fixes the problem.

--
Ondrej Mosnacek <omosnace@redhat dot com>
Software Engineer, Security Technologies
Red Hat, Inc.

  reply	other threads:[~2019-03-26 12:34 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-25 14:50 [kernfs] e19dfdc83b: BUG:KASAN:global-out-of-bounds_in_s kernel test robot
2019-03-25 14:50 ` kernel test robot
2019-03-25 15:16 ` Paul Moore
2019-03-25 17:06   ` Ondrej Mosnacek
2019-03-25 17:06     ` Ondrej Mosnacek
2019-03-26 12:33     ` Ondrej Mosnacek [this message]
2019-03-26 12:33       ` Ondrej Mosnacek
2019-03-26  8:17 ` [PATCH] kernfs: fix xattr name handling in LSM helpers Ondrej Mosnacek
2019-03-26  8:17   ` Ondrej Mosnacek
2019-03-26 12:12 ` [PATCH v2] " Ondrej Mosnacek
2019-03-26 12:12   ` Ondrej Mosnacek
2019-03-29 13:31   ` Paul Moore
2019-04-01  9:47     ` Ondrej Mosnacek
2019-04-01  9:47       ` Ondrej Mosnacek
2019-04-01 10:34 ` [PATCH v3] " Ondrej Mosnacek
2019-04-01 10:34   ` Ondrej Mosnacek
2019-04-02 23:10   ` Paul Moore
2019-04-03  1:23     ` Paul Moore
2019-04-03  7:25       ` Ondrej Mosnacek
2019-04-03  7:25         ` Ondrej Mosnacek
2019-04-04 13:09         ` Paul Moore
2019-04-03  7:29 ` [PATCH v4] " Ondrej Mosnacek
2019-04-03  7:29   ` Ondrej Mosnacek
2019-04-04 13:10   ` Paul Moore

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=CAFqZXNtazgAzoFDMiQWOdaVNcpAH3PEEXwwJ8D+njGoEX4+DvA@mail.gmail.com \
    --to=omosnace@redhat.com \
    --cc=casey@schaufler-ca.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@01.org \
    --cc=paul@paul-moore.com \
    --cc=rong.a.chen@intel.com \
    --cc=selinux@vger.kernel.org \
    --cc=tj@kernel.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.