Kernel panic from malloc() on SUSE 15.1?
Carl Jacobsen
cjacobsen at storix.com
Sat Nov 7 18:44:32 AEDT 2020
On Fri, Nov 6, 2020 at 4:25 AM Michael Ellerman <mpe at ellerman.id.au> wrote:
> So something seems to have gone wrong linking this, I see eg:
>
> 0000000010004a8c <syscall_random>:
> 10004a8c: 2b 10 40 3c lis r2,4139
> 10004a90: 88 f7 42 38 addi r2,r2,-2168
> 10004a94: a6 02 08 7c mflr r0
> 10004a98: 10 00 01 f8 std r0,16(r1)
> 10004a9c: f8 ff e1 fb std r31,-8(r1)
> 10004aa0: 81 ff 21 f8 stdu r1,-128(r1)
> 10004aa4: 78 0b 3f 7c mr r31,r1
> 10004aa8: 60 00 7f f8 std r3,96(r31)
> 10004aac: 68 00 9f f8 std r4,104(r31)
> 10004ab0: 00 00 00 60 nop
> 10004ab4: 30 80 22 e9 ld r9,-32720(r2)
> 10004ab8: 00 00 a9 2f cmpdi cr7,r9,0
> 10004abc: 30 00 9e 41 beq cr7,10004aec <syscall_random+0x60>
> 10004ac0: 60 00 7f e8 ld r3,96(r31)
> 10004ac4: 68 00 9f e8 ld r4,104(r31)
> 10004ac8: 39 b5 ff 4b bl 10000000 <_init-0x1f00>
>
> Notice that last bl (branch and link) to 0x10000000. But there's no text
> at 0x10000000, that's the start of the page which happens to be the ELF
> magic.
>
> I've seen something like this before, but I can't remember when/where so
> I haven't been able to track down what the problem was.
>
> Anyway hopefully someone on the list will know.
>
> That still doesn't explain the kernel crash though.
>
Interesting. Sounds highly unlikely that the linker would have picked
that address at random, but it makes no sense. And, agreed, jumping
into junk should crash the program, not the kernel.
> On my machine it doesn't crash the kernel, so I can catch it later. For
> me it's here:
> ....
ie. in the syscall_random() that I mentioned above.
>
> You should be able to catch it there too if you do:
>
> (gdb) b *0x10000000
> (gdb) r
>
> Hopefully it will stop without crashing the kernel, and then a `bt` will
> show that you're in the same place as me.
>
> If you can get that to work, when you're stopped there, can you do an
> `info registers` and send us the output.
>
Indeed, setting the breakpoint you suggested works, and the stack looks
almost the same - only differences are a few bits off in main's argv
pointer, rand_drbg_get_entropy's pout pointer, and the final address - you
get 0x0000000010000004, I get 0x0000000010000000. Output, including "info
registers", below. Hoping they provide some useful clues. Thanks again for
looking into this.
# gdb --args /tmp/ossl/rand_test
...
(gdb) b *0x10000000
Breakpoint 1 at 0x10000000
(gdb) r
Starting program: /tmp/ossl/rand_test
Breakpoint 1, 0x0000000010000000 in ?? ()
(gdb) bt
#0 0x0000000010000000 in ?? ()
#1 0x0000000010004acc in syscall_random (buf=0x102b0730, buflen=32) at
crypto/rand/rand_unix.c:371
#2 0x00000000100053fc in rand_pool_acquire_entropy (pool=0x102b06e0) at
crypto/rand/rand_unix.c:636
#3 0x0000000010002b58 in rand_drbg_get_entropy (drbg=0x102b02e0,
pout=0x7fffffffecf0, entropy=256, min_len=32,
max_len=2147483647, prediction_resistance=0) at
crypto/rand/rand_lib.c:198
#4 0x000000001001ed9c in RAND_DRBG_instantiate (drbg=0x102b02e0,
pers=0x10248d00 <ossl_pers_string> "OpenSSL NIST SP 800-90A DRBG",
perslen=28) at crypto/rand/drbg_lib.c:338
#5 0x0000000010020300 in drbg_setup (parent=0x0) at
crypto/rand/drbg_lib.c:895
#6 0x0000000010020414 in do_rand_drbg_init () at crypto/rand/drbg_lib.c:924
#7 0x000000001002034c in do_rand_drbg_init_ossl_ () at
crypto/rand/drbg_lib.c:909
#8 0x0000000010005d1c in CRYPTO_THREAD_run_once (once=0x102ab4d8
<rand_drbg_init>,
init=0x1002032c <do_rand_drbg_init_ossl_>) at crypto/threads_none.c:70
#9 0x00000000100209c4 in RAND_DRBG_get0_master () at
crypto/rand/drbg_lib.c:1102
#10 0x0000000010020914 in drbg_status () at crypto/rand/drbg_lib.c:1084
#11 0x0000000010004a58 in RAND_status () at crypto/rand/rand_lib.c:961
#12 0x0000000010002890 in main (argc=1, argv=0x7ffffffff368) at
rand_test.c:6
(gdb) info registers
r0 0x100053fc 268456956
r1 0x7fffffffeaf0 140737488349936
r2 0x102af788 271251336
r3 0x102b0730 271255344
r4 0x20 32
r5 0x30 48
r6 0x102b0760 271255392
r7 0x1 1
r8 0x0 0
r9 0x7fffb7dacc00 140736277957632
r10 0x102b0730 271255344
r11 0x10 16
r12 0x7fffb7e19280 140736278401664
r13 0x7fffb7ffa100 140736280371456
r14 0x0 0
r15 0x0 0
r16 0x0 0
r17 0x0 0
r18 0x0 0
r19 0x0 0
r20 0x0 0
r21 0x0 0
r22 0x0 0
r23 0x0 0
r24 0x0 0
r25 0x0 0
r26 0x0 0
r27 0x7fffb7fef4b8 140736280327352
r28 0x7fffb7ff0000 140736280330240
r29 0x0 0
r30 0x0 0
r31 0x7fffffffeaf0 140737488349936
pc 0x10000000 0x10000000
msr 0x800000010002d033 9223372041149927475
cr 0x44000844 1140852804
lr 0x10004acc 0x10004acc <syscall_random+64>
ctr 0x0 0
xer 0x20000000 536870912
fpscr 0x0 0
vscr 0x0 0
vrsave 0xffffffff -1
ppr 0xc000000000000 3377699720527872
dscr 0x0 0
tar 0x0 0
bescr <unavailable>
ebbhr <unavailable>
ebbrr <unavailable>
mmcr0 0x0 0
mmcr2 0x0 0
siar 0x0 0
sdar 0x0 0
sier 0x0 0
tfhar 0x0 0
texasr 0x0 0
tfiar 0x0 0
cr0 <unavailable>
cr1 <unavailable>
cr2 <unavailable>
cr3 <unavailable>
cr4 <unavailable>
cr5 <unavailable>
cr6 <unavailable>
cr7 <unavailable>
cr8 <unavailable>
cr9 <unavailable>
cr10 <unavailable>
cr11 <unavailable>
cr12 <unavailable>
cr13 <unavailable>
cr14 <unavailable>
cr15 <unavailable>
cr16 <unavailable>
cr17 <unavailable>
cr18 <unavailable>
cr19 <unavailable>
cr20 <unavailable>
cr21 <unavailable>
cr22 <unavailable>
cr23 <unavailable>
cr24 <unavailable>
cr25 <unavailable>
cr26 <unavailable>
cr27 <unavailable>
cr28 <unavailable>
cr29 <unavailable>
cr30 <unavailable>
cr31 <unavailable>
ccr <unavailable>
cxer <unavailable>
clr <unavailable>
cctr <unavailable>
cfpscr <unavailable>
cvscr <unavailable>
cvrsave <unavailable>
cppr <unavailable>
cdscr <unavailable>
ctar <unavailable>
orig_r3 0x10004ac8 268454600
trap 0x700 1792
(gdb)
--
Carl Jacobsen
Storix, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20201106/f0d115ae/attachment-0001.htm>
More information about the Linuxppc-dev
mailing list