linux-kernel - Re: [zer0mem@...oo.com: [oss-security] panic at big_key

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]

Message-ID: <CAOMGZ=HZkPia5q8m7dOeLoOB40qqe5W22qdV6aReQNi8GgsGDg@mail.gmail.com>
Date:	Tue, 26 Jul 2016 11:17:54 +0200
From:	Vegard Nossum <vegard.nossum@...il.com>
To:	David Howells <dhowells@...hat.com>
Cc:	zer0mem@...oo.com, Greg KH <gregkh@...uxfoundation.org>,
	James Morris <james.l.morris@...cle.com>,
	"Serge E. Hallyn" <serge@...lyn.com>,
	"keyrings@...r.kernel.org" <keyrings@...r.kernel.org>,
	"linux-security-module@...r.kernel.org" 
	<linux-security-module@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [zer0mem@...oo.com: [oss-security] panic at big_key_preparse
 #4.7-r6/rc7 & master]

On 26 July 2016 at 09:45, David Howells <dhowells@...hat.com> wrote:
> <zer0mem@...oo.com> wrote:
>
>> If you will have no luck to repro issue, I will take a deeper look at it at
>> Friday and let you know asap
>
> Can you find out the line on which the crash happens?  Load vmlinux into

If you pipe the Code: from the original report into decodecode you get:

$ echo "Code: 5c 41 5d 41 5e 41 5f 5d c3 e8 89 f1 98 ff 4c 8b 25 32 cb
47 02 48 b8 00 00 00 00 00 fc ff df 49 8d 7c 24 48 48 89 fa 48 c1 ea
03 <80> 3c 02 00 0f 85 78 03 00 00 4d 8b 64 24 48 48 b8 00 00 00 00" |
scripts/decodecode
Code: 5c 41 5d 41 5e 41 5f 5d c3 e8 89 f1 98 ff 4c 8b 25 32 cb 47 02
48 b8 00 00 00 00 00 fc ff df 49 8d 7c 24 48 48 89 fa 48 c1 ea 03 <80>
3c 02 00 0f 85 78 03 00 00 4d 8b 64 24 48 48 b8 00 00 00 00
All code
========
  0:   5c                      pop    %rsp
  1:   41 5d                   pop    %r13
  3:   41 5e                   pop    %r14
  5:   41 5f                   pop    %r15
  7:   5d                      pop    %rbp
  8:   c3                      retq
  9:   e8 89 f1 98 ff          callq  0xffffffffff98f197
  e:   4c 8b 25 32 cb 47 02    mov    0x247cb32(%rip),%r12        # 0x247cb47
 15:   48 b8 00 00 00 00 00    movabs $0xdffffc0000000000,%rax
 1c:   fc ff df
 1f:   49 8d 7c 24 48          lea    0x48(%r12),%rdi
 24:   48 89 fa                mov    %rdi,%rdx
 27:   48 c1 ea 03             shr    $0x3,%rdx
 2b:*  80 3c 02 00             cmpb   $0x0,(%rdx,%rax,1)
<-- trapping instruction
 2f:   0f 85 78 03 00 00       jne    0x3ad
 35:   4d 8b 64 24 48          mov    0x48(%r12),%r12
 3a:   48                      rex.W
 3b:   b8 00 00 00 00          mov    $0x0,%eax

I find only two places that plausibly match this:

372:   5b                      pop    %rbx
373:   41 5c                   pop    %r12
375:   41 5d                   pop    %r13
377:   41 5e                   pop    %r14
379:   41 5f                   pop    %r15
37b:   5d                      pop    %rbp
37c:   c3                      retq
37d:   4c 8b 2d 00 00 00 00    mov    0x0(%rip),%r13        # 384
<big_key_preparse+0x164>
384:   48 b8 00 00 00 00 00    movabs $0xdffffc0000000000,%rax
38b:   fc ff df
38e:   49 8d 7d 48             lea    0x48(%r13),%rdi
392:   48 89 fa                mov    %rdi,%rdx
395:   48 c1 ea 03             shr    $0x3,%rdx
399:   80 3c 02 00             cmpb   $0x0,(%rdx,%rax,1)
39d:   0f 85 94 02 00 00       jne    637 <big_key_preparse+0x417>
3a3:   4d 8b 6d 48             mov    0x48(%r13),%r13
3a7:   48 b8 00 00 00 00 00    movabs $0xdffffc0000000000,%rax
3ae:   fc ff df

(this is most likely it since it matches with the pops+ret as well)

and

47d:   4c 8b 25 00 00 00 00    mov    0x0(%rip),%r12        # 484
<big_key_preparse+0x264>
484:   48 b8 00 00 00 00 00    movabs $0xdffffc0000000000,%rax
48b:   fc ff df
48e:   49 8d 7c 24 48          lea    0x48(%r12),%rdi
493:   48 89 fa                mov    %rdi,%rdx
496:   48 c1 ea 03             shr    $0x3,%rdx
49a:   80 3c 02 00             cmpb   $0x0,(%rdx,%rax,1)
49e:   0f 85 04 02 00 00       jne    6a8 <big_key_preparse+0x488>
4a4:   49 8b 44 24 48          mov    0x48(%r12),%rax
4a9:   48 ba 00 00 00 00 00    movabs $0xdffffc0000000000,%rdx
4b0:   fc ff df

That's:

$ addr2line -e security/keys/big_key.o -i 399
include/linux/crypto.h:628
include/linux/crypto.h:1188
security/keys/big_key.c:143

$ addr2line -e security/keys/big_key.o -i 49a
include/crypto/rng.h:112
include/crypto/rng.h:143
include/crypto/rng.h:160
security/keys/big_key.c:84
security/keys/big_key.c:160

Keep in mind that the faulting dereference is a byte comparison
(whereas the dereferences pointed to by those lines should all be
wider) and in fact comes from KASAN itself (KASAN_INLINE). So the
important thing to look for here is probably the dereference offset
0x48(%r12) which corresponds to the crypto_tfm->__crt_alg dereference,
and you see that %r12 is 0 which probably means the tfm is NULL.


Vegard