linux-kernel - Re: unable to handle kernel paging request when inserting FAT32 formatted flash media

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:	Tue, 03 May 2011 11:34:11 +0900
From:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
To:	linux-kernel@...r.kernel.org
Cc:	Rusty Russell <rusty@...tcorp.com.au>
Subject: Re: unable to handle kernel paging request when inserting FAT32 formatted flash media

OGAWA Hirofumi <hirofumi@...l.parknet.co.jp> writes:

> OGAWA Hirofumi <hirofumi@...l.parknet.co.jp> writes:
>
>>> It seems to be interesting exception.
>>>
>>> before relocation (from fat.ko)
>>>     8656:	74 51                	je     86a9 <fat_build_inode+0x2e9>
>>>     8658:	49 c7 c6 00 00 00 00 	mov    $0x0,%r14
>>>     865f:	b2 b6                	mov    $0xb6,%dl
>>>     8661:	80 3d 00 00 00 00 00 	cmpb   $0x0,0x0(%rip) <-- exception
>>>     8668:	74 3f                	je     86a9 <fat_build_inode+0x2e9>
>>>     866a:	49 8d 44 24 08       	lea    0x8(%r12),%rax
>>>
>>> after relocation (from oops)
>>>
>>>   20:	74 51                	je     73 <a+0x73>
>>>   22:	49 c7 c6 d8 91 13 a0 	mov    $0xffffffffa01391d8,%r14
>>>   29:	b2 b6                	mov    $0xb6,%dl
>>>   2b:	3d fc 9b 00 00       	cmp    $0x9bfc,%eax
>>>   30:	00 74 3f 49          	add    %dh,0x49(%rdi,%rdi,1)
>>>   34:	8d 44 24 08          	lea    0x8(%rsp),%eax
>>>
>> relocation info should be this
>>
>>   0x0000000000008663  X86_64_PC32     0x000000000000927c      -5 .LC55
>
> Hm. It seems to be 0x80 was gone somehow. If I added 0x80 at 0x8661, it
> seems to be sane code.
>
>   20:	74 51                	je     73 <a+0x73>
>   22:	49 c7 c6 d8 91 13 a0 	mov    $0xffffffffa01391d8,%r14
>   29:	b2 b6                	mov    $0xb6,%dl
>   2b:	80 3d fc 9b 00 00 00 	cmpb   $0x0,0x9bfc(%rip) <- here is 0x8661
>   32:	74 3f                	je     73 <a+0x73>
>   34:	49 8d 44 24 08       	lea    0x8(%r12),%rax

Code: fd ff ff 0f 1f 80 00 00 00 00 83 ca 01 89 93 10 02 00 00 ba ff 01 00 00 41 f6 85 96 00 00 00 02 74 51 49 c7 c6 d8 91 13 a0 b2 b6 3d fc 9b 00 00 00 74 3f 49 8d 44 24 08 48 89 44 24 08 eb 18 

Oops's Code: was really this? This Code: is missing only <80>, I can't
see why there is no <xx> byte. Even if code was screwed up, I think
Code: should show the <xx>.

> I have no idea how this happened for now. This would be needed to trace
> when happened.
>
> At first, it would be module load time. If you had time to debug and
> trace, I may be able to help to debug it.
>
> Cc: to module maintainer.
>
> Any idea?
>
> Thanks.

-- 
OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
--
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/