From: Dave Jones <davej@codemonkey.org.uk>
To: Kees Cook <keescook@chromium.org>
Cc: Tommi Rantala <tommi.t.rantala@nokia.com>,
Linux-MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
Laura Abbott <labbott@redhat.com>, Ingo Molnar <mingo@kernel.org>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Mark Rutland <mark.rutland@arm.com>,
Eric Biggers <ebiggers@google.com>
Subject: Re: sudo x86info -a => kernel BUG at mm/usercopy.c:78!
Date: Thu, 30 Mar 2017 16:01:00 -0400 [thread overview]
Message-ID: <20170330200100.zcyndf3kimepg77o@codemonkey.org.uk> (raw)
In-Reply-To: <CAGXu5jK8=g8rBx1J4+gC8-3nwRLe2Va89hHX=S-P6SvvgiVb9A@mail.gmail.com>
On Thu, Mar 30, 2017 at 12:52:31PM -0700, Kees Cook wrote:
> On Thu, Mar 30, 2017 at 12:41 PM, Dave Jones <davej@codemonkey.org.uk> wrote:
> > On Thu, Mar 30, 2017 at 09:45:26AM -0700, Kees Cook wrote:
> > > On Wed, Mar 29, 2017 at 11:44 PM, Tommi Rantala
> > > <tommi.t.rantala@nokia.com> wrote:
> > > > Hi,
> > > >
> > > > Running:
> > > >
> > > > $ sudo x86info -a
> > > >
> > > > On this HP ZBook 15 G3 laptop kills the x86info process with segfault and
> > > > produces the following kernel BUG.
> > > >
> > > > $ git describe
> > > > v4.11-rc4-40-gfe82203
> > > >
> > > > It is also reproducible with the fedora kernel: 4.9.14-200.fc25.x86_64
> > > >
> > > > Full dmesg output here: https://pastebin.com/raw/Kur2mpZq
> > > >
> > > > [ 51.418954] usercopy: kernel memory exposure attempt detected from
> > > > ffff880000090000 (dma-kmalloc-256) (4096 bytes)
> > >
> > > This seems like a real exposure: the copy is attempting to read 4096
> > > bytes from a 256 byte object.
> >
> > The code[1] is doing a 4k read from /dev/mem in the range 0x90000 -> 0xa0000
> > According to arch/x86/mm/init.c:devmem_is_allowed, that's still valid..
> >
> > Note that the printk is using the direct mapping address. Is that what's
> > being passed down to devmem_is_allowed now ? If so, that's probably what broke.
>
> So this is attempting to read physical memory 0x90000 -> 0xa0000, but
> that's somehow resolving to a virtual address that is claimed by
> dma-kmalloc?? I'm confused how that's happening...
The only thing that I can think of would be a rogue ptr in the bios
table, but that seems unlikely. Tommi, can you put strace of x86info -mp somewhere?
That will confirm/deny whether we're at least asking the kernel to do sane things.
Dave
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Dave Jones <davej@codemonkey.org.uk>
To: Kees Cook <keescook@chromium.org>
Cc: Tommi Rantala <tommi.t.rantala@nokia.com>,
Linux-MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
Laura Abbott <labbott@redhat.com>, Ingo Molnar <mingo@kernel.org>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Mark Rutland <mark.rutland@arm.com>,
Eric Biggers <ebiggers@google.com>
Subject: Re: sudo x86info -a => kernel BUG at mm/usercopy.c:78!
Date: Thu, 30 Mar 2017 16:01:00 -0400 [thread overview]
Message-ID: <20170330200100.zcyndf3kimepg77o@codemonkey.org.uk> (raw)
In-Reply-To: <CAGXu5jK8=g8rBx1J4+gC8-3nwRLe2Va89hHX=S-P6SvvgiVb9A@mail.gmail.com>
On Thu, Mar 30, 2017 at 12:52:31PM -0700, Kees Cook wrote:
> On Thu, Mar 30, 2017 at 12:41 PM, Dave Jones <davej@codemonkey.org.uk> wrote:
> > On Thu, Mar 30, 2017 at 09:45:26AM -0700, Kees Cook wrote:
> > > On Wed, Mar 29, 2017 at 11:44 PM, Tommi Rantala
> > > <tommi.t.rantala@nokia.com> wrote:
> > > > Hi,
> > > >
> > > > Running:
> > > >
> > > > $ sudo x86info -a
> > > >
> > > > On this HP ZBook 15 G3 laptop kills the x86info process with segfault and
> > > > produces the following kernel BUG.
> > > >
> > > > $ git describe
> > > > v4.11-rc4-40-gfe82203
> > > >
> > > > It is also reproducible with the fedora kernel: 4.9.14-200.fc25.x86_64
> > > >
> > > > Full dmesg output here: https://pastebin.com/raw/Kur2mpZq
> > > >
> > > > [ 51.418954] usercopy: kernel memory exposure attempt detected from
> > > > ffff880000090000 (dma-kmalloc-256) (4096 bytes)
> > >
> > > This seems like a real exposure: the copy is attempting to read 4096
> > > bytes from a 256 byte object.
> >
> > The code[1] is doing a 4k read from /dev/mem in the range 0x90000 -> 0xa0000
> > According to arch/x86/mm/init.c:devmem_is_allowed, that's still valid..
> >
> > Note that the printk is using the direct mapping address. Is that what's
> > being passed down to devmem_is_allowed now ? If so, that's probably what broke.
>
> So this is attempting to read physical memory 0x90000 -> 0xa0000, but
> that's somehow resolving to a virtual address that is claimed by
> dma-kmalloc?? I'm confused how that's happening...
The only thing that I can think of would be a rogue ptr in the bios
table, but that seems unlikely. Tommi, can you put strace of x86info -mp somewhere?
That will confirm/deny whether we're at least asking the kernel to do sane things.
Dave
next prev parent reply other threads:[~2017-03-30 20:01 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-30 6:44 sudo x86info -a => kernel BUG at mm/usercopy.c:78! Tommi Rantala
2017-03-30 6:44 ` Tommi Rantala
2017-03-30 16:45 ` Kees Cook
2017-03-30 16:45 ` Kees Cook
2017-03-30 17:20 ` Mark Rutland
2017-03-30 17:20 ` Mark Rutland
2017-03-30 17:27 ` Laura Abbott
2017-03-30 17:27 ` Laura Abbott
2017-03-30 17:37 ` Kees Cook
2017-03-30 17:37 ` Kees Cook
2017-03-30 17:44 ` Laura Abbott
2017-03-30 17:44 ` Laura Abbott
2017-03-31 5:44 ` Tommi Rantala
2017-03-31 5:44 ` Tommi Rantala
2017-03-30 19:41 ` Dave Jones
2017-03-30 19:41 ` Dave Jones
2017-03-30 19:52 ` Kees Cook
2017-03-30 19:52 ` Kees Cook
2017-03-30 20:01 ` Dave Jones [this message]
2017-03-30 20:01 ` Dave Jones
2017-03-31 5:40 ` Tommi Rantala
2017-03-31 5:40 ` Tommi Rantala
2017-03-31 6:59 ` Tommi Rantala
2017-03-31 6:59 ` Tommi Rantala
2017-03-31 17:17 ` Dave Jones
2017-03-31 17:17 ` Dave Jones
2017-03-31 17:32 ` Kees Cook
2017-03-31 17:32 ` Kees Cook
2017-03-31 18:03 ` Dave Jones
2017-03-31 18:03 ` Dave Jones
2017-03-31 18:57 ` Andy Lutomirski
2017-03-31 18:57 ` Andy Lutomirski
2017-03-31 18:26 ` Linus Torvalds
2017-03-31 18:26 ` Linus Torvalds
2017-03-31 19:32 ` Tommi Rantala
2017-03-31 19:32 ` Tommi Rantala
2017-04-04 22:37 ` Kees Cook
2017-04-04 22:37 ` Kees Cook
2017-04-04 22:55 ` Linus Torvalds
2017-04-04 22:55 ` Linus Torvalds
2017-04-04 22:59 ` Kees Cook
2017-04-04 22:59 ` Kees Cook
2017-04-05 0:22 ` Linus Torvalds
2017-04-05 0:22 ` Linus Torvalds
2017-04-05 19:39 ` Kees Cook
2017-04-05 19:39 ` Kees Cook
2017-03-31 23:58 ` Kees Cook
2017-03-31 23:58 ` Kees Cook
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=20170330200100.zcyndf3kimepg77o@codemonkey.org.uk \
--to=davej@codemonkey.org.uk \
--cc=ebiggers@google.com \
--cc=jpoimboe@redhat.com \
--cc=keescook@chromium.org \
--cc=labbott@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mark.rutland@arm.com \
--cc=mingo@kernel.org \
--cc=tommi.t.rantala@nokia.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.