linux-kernel - Re: 2.6.28-rc6-git1 -- BUG: unable to handle kernel paging request at ffff8800be8b0019

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]

Message-ID: <Pine.LNX.4.64.0811272136260.1747@blonde.site>
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/