linux-kernel - Re: [linux-usb-devel] 2.6.19-rc1-mm1 - locks when using "dd bs=1M" from card reader

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-next>] [day] [month] [year] [list]

Date:	Thu, 19 Oct 2006 14:25:40 +0200
From:	Helge Hafting <helge.hafting@...el.hist.no>
To:	Alan Stern <stern@...land.harvard.edu>
CC:	Paolo Ornati <ornati@...twebnet.it>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	USB development list <linux-usb-devel@...ts.sourceforge.net>
Subject: Re: [linux-usb-devel] 2.6.19-rc1-mm1 - locks when using "dd bs=1M"
 from card reader

Alan Stern wrote:
> On Wed, 18 Oct 2006, Helge Hafting wrote:
>   
[...]
> That's why I asked for the USB debugging logs (which you forgot to include
> here).
>   
Attached dmesg.gz with lots of usb messages.

>> To bring it down:
>>
>> dd if=/dev/sdc of=sdc.dump bs=1M
>>     
This time, it seems to have crashed on the first megabyte.
I mounted the filesystem synchronously, and still I had 0 bytes
in the dumpfile.  The crash also came with no delay after
pressing enter.

> It's possible that both of these are caused by something unrelated 
> overwriting kernel memory.
>   
something like a function pointer mistaken for a data pointer?
> By the way, what happens if you add a "skip=" argument to dd so that the 
> copy begins near the end of the device?  Does the oops then occur that 
> much sooner?
>   
No, it is random. May happen immediately, may happen after a while.
I even had "cfdisk /dev/sdc" crash on me fresh after a reboot.
> Oh, and the next time this happens, could you copy down all of the code
> bytes from the oops message?  And also provide the section from "objdump
> -d drivers/usb/host/ehci-hcd.o" for the start_unlink_async routine?
>   
objdump for start_unlink_async attached.

 From the BUG:

Stack (All I got before it rebooted after 300s)
00000010 c0664dc8 dff84000 dffdbc00 dffdb600 00000296
df9244c0 c03248de c0664dc8

EIP: [<c031f823>] start_unlink_async+0x16/0xf2
SS:ESP:0068:c0664d58



Code (Complete) 5d e9 8e 31 ff ff f6 43 28 01 75 b8 c7 43 24 00 00 00 00 
eb af
57 56 53 83 ec 10 89 c6 89 d3 8b 48 04 8b 39 8b 40 14 85 c0 74
6f <0f> 0b 39 5e 10 74 78 c6 43 68 02 8d 43 60 e8 9f 3c f1 ff 89 5e

I found this in the start_unlink_async dump - here it is with the
same line breaking as well as the differences:
{Before start_unlink_async}
5d
e9 8e 31 ff ff        ; objdump has "e9 fc ff ff ff" here, it is a jump
f6 43 28 01
75 b8
c7 43 24 00 00 00 00
eb af
start_unlink_async
57
56
53
83 ec 10
89 c6
89 d3
8b 48 04
8b 39
8b 40 14
85 c0
74 6f
0f 0b
39 5e 10
74 78
c6 43 68 02
8d 43 60
e8 9f 3c f1 ff ; objdump has "e8 fc ff ff ff" here, a call
89 5e

Calls and jumps are different, but I guess that is just linking effects?

Hope this is useful,
Helge Hafting

Download attachment "dmesg.gz" of type "application/gzip" (10451 bytes)

View attachment "objdump.start_unlink_async" of type "text/plain" (5409 bytes)