Messages in this thread | | | From | Vegard Nossum <> | Date | Tue, 26 Jul 2016 11:17:54 +0200 | Subject | Re: [: [oss-security] panic at big_key_preparse #4.7-r6/rc7 & master] |
| |
On 26 July 2016 at 09:45, David Howells <dhowells@redhat.com> wrote: > <zer0mem@yahoo.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
| |