linux-kernel - Re: -tip: origin tree boot crash

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

Date:	Fri, 18 Dec 2009 12:10:35 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ingo Molnar <mingo@...e.hu>
cc:	linux-kernel@...r.kernel.org, Dave Hansen <dave@...1.net>,
	Richard Purdie <rpurdie@...ux.intel.com>
Subject: Re: -tip: origin tree boot crash



On Fri, 18 Dec 2009, Ingo Molnar wrote:
> [   75.151208] calling  nas_gpio_init+0x0/0x153 @ 1
> [   75.155860] BUG: unable to handle kernel paging request at 00000000001de7d0
> [   75.159841] IP: [<ffffffff81683c55>] strstr+0x20/0x5f

Ok, the disassembly is

   b:	55                   	push   %rbp
   c:	48 89 f2             	mov    %rsi,%rdx
   f:	48 89 e5             	mov    %rsp,%rbp
  12:	eb 03                	jmp    0x17
  14:	48 ff c2             	inc    %rdx
  17:	80 3a 00             	cmpb   $0x0,(%rdx)
  1a:	75 f8                	jne    0x14
  1c:	29 f2                	sub    %esi,%edx
  1e:	48 89 f8             	mov    %rdi,%rax
  21:	74 45                	je     0x68
  23:	48 89 f9             	mov    %rdi,%rcx
  26:	eb 03                	jmp    0x2b
  28:	48 ff c1             	inc    %rcx
  2b:*	80 39 00             	cmpb   $0x0,(%rcx)     <-- trapping instruction
  2e:	75 f8                	jne    0x28
  30:	48 89 f8             	mov    %rdi,%rax
  33:	4c 63 d2             	movslq %edx,%r10
  36:	eb 26                	jmp    0x5e

so if I read that code right, that's a 'strlen()' on %rdi, which is the 
first argument to strstr().

So it would be that 

	l1 = strlen(s1);

thing, and 's1' is bad.

Which in turn means:

> [   75.159841] Call Trace:
> [   75.159841]  [<ffffffff825f0dfb>] dmi_matches+0x6f/0x8d

that since the call is

	strstr(dmi_ident[s], dmi->matches[i].substr)

that it is the "dmi_ident[]" array itself that is broken.

The DMI code doesn't seem to be very careful about checking the array 
accesses against DMI_STRING_MAX. So I wonder if this is actually a DMI 
bug, not a driver bug - and that the driver just is able to trigger that 
bug somehow where others have not.

		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/