[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201306141636.29390.arnd@arndb.de>
Date: Fri, 14 Jun 2013 16:36:29 +0200
From: Arnd Bergmann <arnd@...db.de>
To: James Bottomley <James.Bottomley@...senpartnership.com>
Cc: Marek Szyprowski <m.szyprowski@...sung.com>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Michal Simek <michal.simek@...inx.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Michal Simek <monstr@...str.eu>,
"Linux-Arch" <linux-arch@...r.kernel.org>
Subject: Re: [PATCH] dma-mapping: Add BUG_ON for uninitialized dma_ops
On Thursday 13 June 2013, James Bottomley wrote:
> On Wed, 2013-06-12 at 17:06 +0200, Arnd Bergmann wrote:
> > On Tuesday 11 June 2013, James Bottomley wrote:
> > > Really, no, it's not a good idea at all. It invites tons of patches
> > > littering the code with BUG_ONs where we might possibly get a NULL
> > > dereference. All it does is add extra instructions to a code path for
> > > no actual benefit.
> > >
> > > If you can answer the question: what more information does the BUG_ON
> > > give you than the NULL deref Oops would not? then it might be
> > > reasonable.
> >
> > The question is if a user can trigger the NULL dereference intentionally,
> > in which case they might get the kernel to jump into a user-provided
> > buffer.
>
> Can you elaborate on how they could do this? If you're thinking they
> could alter the pointer and trigger the jump, then yes, but a BUG_ON
> won't prevent that because the altered pointer won't be NULL.
The attack that has been demonstrated a couple of times uses an anomymous
mmap to virtual address 0. You fill that page with pointers to a
function in your program. If there is a NULL pointer to some operations
structure and kernel code calls an operation without checking the
ops pointer first, it gets read from the NULL page and the kernel
jumps into user space.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists