From: Al Viro <viro@ZenIV.linux.org.uk>
To: Zeno Davatz <zdavatz@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.6.31-rc1 crashes randomly on my Machine.
Date: Fri, 26 Jun 2009 08:39:19 +0100 [thread overview]
Message-ID: <20090626073919.GD8633@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20090626071520.GC8633@ZenIV.linux.org.uk>
On Fri, Jun 26, 2009 at 08:15:21AM +0100, Al Viro wrote:
> On Fri, Jun 26, 2009 at 08:56:52AM +0200, Zeno Davatz wrote:
>
> > Jun 25 21:19:12 zenogentoo Code: 00 00 00 c7 47 20 00 00 00 00 c7 47
> > 24 00 00 00 00 c7 47 10 00 00 00 00 c7 47 14 00 00 00 00 c7 47 0c 00
> > 00 00 00 e9 27 ff ff ff <ff> 89 e5 57 56 53 83 ec 34 89 45 d0 89 55 cc
> > 89 4d c8 8b 70 6c
> > Jun 25 21:19:12 zenogentoo EIP: [<c10d1d35>] seq_read+0x0/0x3a5 SS:ESP
> > 0068:f4b01f44
> > Jun 25 21:19:12 zenogentoo CR2: 0000000053565be5
> > Jun 25 21:19:12 zenogentoo ---[ end trace 6254fef9dc80950b ]---
> > Jun 25 21:19:12 zenogentoo BUG: unable to handle kernel paging request
> > at 53565be5
>
> Real cute... Disassembly of that sucker:
> decl 0x535657e5(%ecx)
> which matches nicely the address in page fault. However, that doesn't
> look even remotely plausible for a beginning of function. OTOH,
> disassembly at one byte offset from that gives
> mov %esp,%ebp
> push %edi
> push %esi
> push %ebx
> which is exactly what you'd expect to see in such place.
Actually, it's not *quite* what you'd expect to see. What's missing is
push %ebp
as the first instruction, preceding that stuff. And it would take one
byte, so...
> IOW, you've
> got an off-by-one - it had jumped at one byte before the actual entry
> point of seq_read().
... this is not an off-by-one at all. The first byte of function code
got overwritten with 0xff. Code before that doesn't seem to be mangled -
it's
movl $0x0,0x20(%edi)
movl $0x0,0x24(%edi)
movl $0x0,0x10(%edi)
movl $0x0,0x14(%edi)
movl $0x0,0xc(%edi)
jmp <a bit back>
which is at least not entirely implausible. So it seems to be a memory
corruption in .text, which might or might not affect the directly
preceding bytes (0xe9 <signed 32bit int> is a relative jump, so there's
no way to tell whether this 0xff had been the only byte affected - it
would be preceded by 3 0xff coming from small negative integer anyway).
next prev parent reply other threads:[~2009-06-26 7:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-26 6:56 2.6.31-rc1 crashes randomly on my Machine Zeno Davatz
2009-06-26 7:15 ` Al Viro
2009-06-26 7:39 ` Al Viro [this message]
2009-06-27 11:10 ` Zeno Davatz
2009-06-27 16:42 ` Al Viro
2009-06-29 6:35 ` Zeno Davatz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090626073919.GD8633@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=zdavatz@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox