On Thursday 26 May 2005 10:47, Jeff Garzik wrote:
> Does the attached patch change things?
Yes. As soon as first ata error occurs:
22:01:59.006541500 kern.err: ata1: command 0x25 timeout, stat 0x50 host_stat 0x1
22:01:59.007252500 kern.alert: Unable to handle kernel paging request at virtual address 6b6b6b6b
22:01:59.008197500 kern.alert: printing eip:
22:01:59.009304500 kern.info: c03b5d7a
22:01:59.010231500 kern.alert: *pde = 00000000
22:01:59.010919500 kern.alert: Oops: 0000 [#1]
22:01:59.011948500 kern.info: Modules linked in: snd_pcm_oss snd_mixer_oss snd_intel8x0 snd_ac97_codec snd_pcm snd_timer snd soundcore snd_page_alloc ipt_REDIRECT ipt_MASQUERADE ipt_multiport ipt_state iptable_nat ip_conntrack iptable_filter cls_u32 sch_htb iptable_mangle autofs ip_tables
22:01:59.012521500 kern.info: CPU: 0
22:01:59.013618500 kern.info: EIP: 0060:[<c03b5d7a>] Not tainted VLI
22:01:59.014569500 kern.info: EFLAGS: 00010202 (2.6.12-rc2-cl)
22:01:59.015709500 kern.info: EIP is at scsi_try_to_abort_cmd+0xa/0x50
22:01:59.016749500 kern.info: eax: 6b6b6b6b ebx: c19d0460 ecx: c19d0460 edx: c19d0478
22:01:59.017802500 kern.info: esi: c19cffb4 edi: c19cffb4 ebp: c19cff84 esp: c19cff80
22:01:59.018791500 kern.info: ds: 007b es: 007b ss: 0068
22:01:59.019865500 kern.info: Process scsi_eh_0 (pid: 478, threadinfo=c19cf000 task=c1968530)
22:01:59.020918500 kern.info: Stack: c19d0460 c19cff9c c03b5eb7 c19d0460 c19d0478 c19cffb4 00000246 c19cffc8
22:01:59.021945500 kern.info: c03b6a92 c19cffb4 c19cffac c19cffac c19cffac c19d0478 c19d0478 c19cffd4
22:01:59.023051500 kern.info: dfc1507c 00000000 c19cffec c03b6b16 dfc1507c 00000000 00000000 c19cffdc
22:01:59.023907500 kern.info: Call Trace:
22:01:59.025073500 kern.info: [<c0103cc5>] show_stack+0x75/0x90
22:01:59.027613500 kern.info: [<c0103e19>] show_registers+0x119/0x190
22:01:59.028311500 kern.info: [<c0103ff5>] die+0xb5/0x130
22:01:59.029231500 kern.info: [<c0110728>] do_page_fault+0x458/0x6d6
22:01:59.030303500 kern.info: [<c01038ef>] error_code+0x4f/0x60
22:01:59.031213500 kern.info: [<c03b5eb7>] scsi_eh_abort_cmds+0x37/0x90
22:01:59.032241500 kern.info: [<c03b6a92>] scsi_invoke_strategy_handler+0xd2/0xf0
22:01:59.033137500 kern.info: [<c03b6b16>] scsi_error_handler+0x66/0xd0
22:01:59.033840500 kern.info: [<c0100cc5>] kernel_thread_helper+0x5/0x10
22:01:59.034854500 kern.info: Code: 00 00 00 5d c3 8b 43 38 89 43 34 8b 4d 0c 51 53 e8 1c ff ff ff 58 5a eb 88 90 8d b4 26 00 00 00 00 55 89 e5 8b 4d 08 53 8b 41 04 <8b> 00 8b 40 5c 8b 40 20 85 c0 ba 03 20 00 00 74 23 8b 59 2c 85
We hit use-after-free here:
static int scsi_try_to_abort_cmd(struct scsi_cmnd *scmd)
{
unsigned long flags;
int rtn = FAILED;
if (!scmd->device->host->hostt->eh_abort_handler)
return rtn;
Seems like struct scsi_cmnd pointed by scmd is filled by slab poisoning pattern:
000007d0 <scsi_try_to_abort_cmd>:
7d0: 55 push %ebp
7d1: 89 e5 mov %esp,%ebp
7d3: 8b 4d 08 mov 0x8(%ebp),%ecx ecx = scmd
7d6: 53 push %ebx
7d7: 8b 41 04 mov 0x4(%ecx),%eax eax = scmd->device (0x6b6b6b6b6)
7da: 8b 00 mov (%eax),%eax trying to get scmd->device->host, BOOM
7dc: 8b 40 5c mov 0x5c(%eax),%eax
7df: 8b 40 20 mov 0x20(%eax),%eax
7e2: 85 c0 test %eax,%eax
7e4: ba 03 20 00 00 mov $0x2003,%edx
7e9: 74 23 je 80e <scsi_try_to_abort_cmd+0x3e>
--
vda
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
