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]

Date:	Thu, 27 Nov 2008 23:23:55 +0200
From:	Pekka Enberg <penberg@...helsinki.fi>
To:	Hugh Dickins <hugh@...itas.com>
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

Hi Hugh,

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.

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.

		Pekka
--
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/