linux-kernel - Re: Latest git oopses during boot

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

Date:	Thu, 7 Feb 2008 10:18:43 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Harald Arnesen <skogtun.linux@...il.com>
cc:	FUJITA Tomonori <tomof@....org>, akpm@...ux-foundation.org,
	matthew@....cx, linux-kernel@...r.kernel.org,
	linux-scsi@...r.kernel.org, fujita.tomonori@....ntt.co.jp
Subject: Re: Latest git oopses during boot



On Thu, 7 Feb 2008, Harald Arnesen wrote:
> 
> OK, tried it. Another screen shot attached
> (I must really get another box to use as a serial terminal).

This oops decodes to

     8b 44 24 10             mov    0x10(%esp),%eax
     8b 90 7c 02 00 00       mov    0x27c(%eax),%edx
     83 ea 54                sub    $0x54,%edx
     24 18                   and    $0x18,%al
     8b 4c 24 14             mov    0x14(%esp),%ecx
     f6 41 04 04             testb  $0x4,0x4(%ecx)
     75 57                   jne    0x70
     ba d0 80 00 00          mov    $0x80d0,%edx
     b8 68 bf 30 c0          mov    $0xc030bf68,%eax
     e8 2f 8a 38 c7          call   0xc7388a57
**   a3 14 00 00 00          mov    %eax,0x14	**
     85 c0                   test   %eax,%eax
     0f 84 b3 14 00 00       je     0x14c0
     8b 44 24 14             mov    0x14(%esp),%eax
     83 c0 0c                add    $0xc,%eax

and the oopsing instruction is literally an insane "store to absolute
address 0x14" which will definitely oops unconditionally. 

Quit frankly, that code makes no sense.  It smells like code corruption,
especially as it is right at a return point of a function call (ie maybe
the function screwed up the stack accesses somehow).

Actually, it look slike the call address itself is screwed up too.  I
don't think "0xc7388a57" is likely to be a valid address.

The code *looks* like the test

	if (ASC_NARROW_BOARD(boardp)) {
		ASC_DBG(1, "narrow board\n");
		asc_dvc_varp = &boardp->dvc_var.asc_dvc_var;
		asc_dvc_varp->bus_type = bus_type;

but with strange corruption. 

Can you do a

	make drivers/scsi/advansys.lst

and see what it should be?

		Linus
--
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/