lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 27 Nov 2008 21:56:20 +0000 (GMT)
From:	Hugh Dickins <hugh@...itas.com>
To:	Pekka Enberg <penberg@...helsinki.fi>
cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Miles Lane <miles.lane@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Christoph Lameter <cl@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>, Tejun Heo <htejun@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Vegard Nossum <vegard.nossum@...il.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: 2.6.28-rc6-git1 -- BUG: unable to handle kernel paging request
 at ffff8800be8b0019

On Thu, 27 Nov 2008, Pekka Enberg wrote:
> Hugh Dickins wrote:
> > Reverting my patch for now: that's certainly a reasonable possibility,
> > but leaves us with several other such bugs.  Suggested patch below,
> > but the ftrace part of it worries me a little, since it's within a
> > structure and maybe it's a bad idea to enlarge that at this point;
> > I've also not _really_ done the arithmetic needed for the slub one.
> 
> For SLUB, I think you can just replace the 100 with KSYM_NAME_LEN and it will
> work fine. The 100 constant is already supposed to be big enough to fit the
> symbol and the rest.

That would fix the bug that my sprint_symbol patch has exposed
(or introduced, according to your perspective!); but that 100 can only
be big enough to fit symbol and all the rest if you assume that maximum
symbol length is ... I'm not sure exactly ... somewhere around 20 bytes?

If we assume that, then why does KSYM_NAME_LEN allow 128?  I'll agree
that 128 seems rather on the high side (I'd abhor symbols of anywhere
near that length in any code I came near), but that's what's allowed,
so shouldn't SLUB be going along with that?

> 
> Hugh Dickins wrote:
> > An alternative quick just-for-now fix might be to remove that
> > 	namebuf[KSYM_NAME_LEN - 1] = 0;
> > from kallsyms_lookup(): as I understand it (please check), that
> > could only make sense in cases where the symbol is KSYM_NAME_LEN
> > long or longer - in which case, all of the places fixed in the
> > patch below would be causing corruption already, even without my
> > patch.  I think.  Maybe that "= 0" even serves no purpose at all?
> 
> I like this approach the best but I worry it's a can of worms especially this
> late in the cycle.
> 
> As a stop-gap measure, I'm fine with your proposed patch either as-is or with
> the suggestions I had for the SLUB case.

I'd be _much_ happier with my proposed patch if we get an Ack from
Steven on the ftrace.h part of it.

Hugh
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ