Messages in this thread | | | Date | Thu, 27 Nov 2008 16:13:11 +0200 | From | "Pekka Enberg" <> | Subject | Re: 2.6.28-rc6-git1 -- BUG: unable to handle kernel paging request at ffff8800be8b0019 |
| |
Hi Hugh,
(I'm adding Vegard to the cc as he pointed out the same thing.)
On Thu, Nov 27, 2008 at 3:54 PM, Hugh Dickins <hugh@veritas.com> wrote: > I think you're looking at a 2.6.28-rc5 sprint_symbol() there: > the world has moved on since those days. I changed it to use the > supplied "buffer" instead of local "namebuf" in 2.6.28-rc6, so we > have to wonder if my patch is to blame - though I don't see it. > > Sorry, I'm eating lunch then about to go out for a couple of hours: > can't look into it now, but maybe this info will help you to make > better sense of what's going on.
Oh, right. I think I see where this is going. The buffer is coming from sysfs and is PAGE_SIZE long. In SLUB, we do check for overflows but list_locations() allows us to get as close as 100 bytes bytes from the edge of the page. Unfortunately, kallsyms_lookup() does:
const char *kallsyms_lookup(unsigned long addr, unsigned long *symbolsize, unsigned long *offset, char **modname, char *namebuf) { namebuf[KSYM_NAME_LEN - 1] = 0; namebuf[0] = 0;
where KSYM_NAME_LEN is 128 which will tip us over the page edge potentially triggering an oops. The proper fix is probably to pass a length of namebuf to kallsyms_lookup() but it's probably best to revert the patch this late in the release cycle?
Pekka
| |