linux-kernel - Re: [BUG] NULL pointer dereference in 3.7-rc7 (syscall_trace

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:	Thu, 29 Nov 2012 15:22:20 +0100
From:	Borislav Petkov <bp@...en8.de>
To:	Ian Kumlien <pomac@...or.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [BUG] NULL pointer dereference in 3.7-rc7 (syscall_trace_enter)

On Thu, Nov 29, 2012 at 01:27:08PM +0100, Ian Kumlien wrote:
> I think that chrome does traceing all the time as a part of it's
> sandbox - this is most likely chrome monitoring flash...

Ah, ok.

> BUG: unable to handle kernel NULL pointer dereference at
> 0000000000000063
> IP: [<ffffffff8100b64b>] syscall_trace_enter+0x15e/0x191
> PGD 0
> Oops: 0000 [#1] PREEMPT SMP
> Modules linked in: snd_usb_audio snd_usbmidi_lib nouveau mxm_wmi wmi
> i2x_algo_bit ttm drm_kms_helper drm
> CPU 0
> Pid: 24590, comm: chrome Not tainted 3.7.0-rc7 #50 System manufacturer
> System Product Name/A8N32-SLI-Deluxe
> RIP: 0010:[<ffffffff8100b64b>] [<ffffffff8100b64b>]
> syscall_trace_enter+0x15e/0x191
> RSP: 0018:ffff8800058e3f38 EFLAGS: 00010206
> RAX: 0000000000000081 RBX: ffff8800058e3f58 RCX: 0000000000000063
> RDX: 00007fe1f2fbde18 RSI: 00000000000000ca RDI: 00007fe1f2fbde18
> RBP: 0000000000000000 R08: 0000000000000001 R09: 00007fe23f9fcb10
> R10: 00007fe23f9fcb10 R11: 0000000000000206 R12: 0000000000000032
> R13: 00007fe23f9fd9c0 R14: 00007fe25d743710 R15: 0000000000000007
> FS:  00007fe23f9fd700(0000) GS:ffff88013fc00000(0000)
> knlGS:00000000f5c88740
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000063 CR3: 0000000083a84000 CR4: 00000000000007f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process chrome (pid: 24590, threadinfo ffff8800058e2000, task
> ffff88003dacd3b0)
> Stack:
>  00007fe1f2fbde10 0000000000000001 0000000000000032 ffffffff8160646c
>  0000000000000007 00007fe25d743710 00007fe23f9fd9c0 0000000000000032
>  0000000000000001 00007fe1f2fbde10 0000000000000206 00007fe23f9fcb10
> Call Trace:
>  [<ffffffff8160646c>] ? tracesys+0x7e/0xe2
> Code: 53 28 48 85 ff 74 29 83 3f 00 75 24 eb 37 65 48 8b 0c 25 80 b8 00
> 00 48 8b 89 c0 04 00 00 4c 8b 4b 38 48 8b 53 70 48 85 c9 74 08 <83> 39
> 00 74 1f 48 83 ca ff 48 85 ed 75 04 48 8b 53 78 5b 5d 48
> RIP  [<ffffffff8100b64b>] syscall_trace_eneter+0x15e/0x191
>  RSP <ffff8800058e3f38>
> CR2: 0000000000000063

Right, so I can get the code now where it happens, but it is pretty
unreliable to map it to what my compiler generates here (of course,
different compilers and hardware):

Code: 53 28 48 85 ff 74 29 83 3f 00 75 24 eb 37 65 48 8b 0c 25 80 b8 00 00 48 8b 89 c0 04 00 00 4c 8b 4b 38 48 8b 53 70 48 85 c9 74 08 <83> 39 00 74 1f 48 83 ca ff 48 85 ed 75 04 48 8b 53 78 5b 5d 48
All code
========
   0:   53                      push   %rbx
   1:   28 48 85                sub    %cl,-0x7b(%rax)
   4:   ff 74 29 83             pushq  -0x7d(%rcx,%rbp,1)
   8:   3f                      (bad)  
   9:   00 75 24                add    %dh,0x24(%rbp)
   c:   eb 37                   jmp    0x45
   e:   65 48 8b 0c 25 80 b8    mov    %gs:0xb880,%rcx
  15:   00 00 
  17:   48 8b 89 c0 04 00 00    mov    0x4c0(%rcx),%rcx
  1e:   4c 8b 4b 38             mov    0x38(%rbx),%r9
  22:   48 8b 53 70             mov    0x70(%rbx),%rdx
  26:   48 85 c9                test   %rcx,%rcx
  29:   74 08                   je     0x33
  2b:*  83 39 00                cmpl   $0x0,(%rcx)     <-- trapping instruction
  2e:   74 1f                   je     0x4f
  30:   48 83 ca ff             or     $0xffffffffffffffff,%rdx
  34:   48 85 ed                test   %rbp,%rbp
  37:   75 04                   jne    0x3d
  39:   48 8b 53 78             mov    0x78(%rbx),%rdx
  3d:   5b                      pop    %rbx
  3e:   5d                      pop    %rbp
  3f:   48                      rex.W

So we oops when we try to deref 0x63 which is, of course, not a valid
pointer. The question is, what exactly is that thing in rcx. It looks
like a percpu variable to me but I'm not sure.

Can you do:

make arch/x86/kernel/ptrace.lst

and send me that file, privately is fine too.

Thanks.

-- 
Regards/Gruss,
    Boris.
--
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/