Re: 3.5-rc6 dentry related GPF

Dave Jones
2012-07-11T19:18:58Z

On Wed, Jul 11, 2012 at 12:10:12PM -0700, Linus Torvalds wrote:
> On Wed, Jul 11, 2012 at 11:32 AM, Dave Jones <davej@redhat.com> wrote:
> >
> > What's puzzling me though is how we got from do_dentry_open to try_module_get ?
>
> It's the
>
> f->f_op = fops_get(inode->i_fop);
>
> that does it.
>
> I have no idea what the actual bug is, though, but the code decodes to
>
> 0: 89 75 f0 mov %esi,-0x10(%rbp)
> 3: 4c 89 7d f8 mov %r15,-0x8(%rbp)
> 7: 66 66 66 66 90 data32 data32 data32 xchg %ax,%ax
> c: b8 01 00 00 00 mov $0x1,%eax
> 11: 48 85 ff test %rdi,%rdi
> 14: 48 89 fb mov %rdi,%rbx
> 17: 74 42 je 0x5b
> 19: 65 48 8b 04 25 b0 c8 mov %gs:0xc8b0,%rax
> 20: 00 00
> 22: 83 80 44 e0 ff ff 01 addl $0x1,-0x1fbc(%rax)
> 29:* 83 3f 02 cmpl $0x2,(%rdi) <-- trapping instruction
> 2c: 0f 84 54 01 00 00 je 0x186
> 32: 48 8b 87 50 02 00 00 mov 0x250(%rdi),%rax
> 39: 65 48 ff 00 incq %gs:(%rax)
>
> where that "cmpl $2" is the "module_is_live(module)" test, as far as I
> can tell. And %rdi should be the module pointer, but it is obviously
> garbage:
>
> rdi = 54415541e5894855
>
> which looks like some odd corrupted ASCII to me ("UH\211\345AUAT") but
> that makes no sense either.

I fixed some really stupid braino in my fuzzer last night, so oopses are
falling out left and right since then. It's probably only a matter of
time before I walk into this again. Perhaps with more data it'll start
to make sense.

Dave