| 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
| ||
|
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
Powered by blists - more mailing lists