Bug #3194
closed
dis crashes disassembling aes
100%
Description
On my (gcc-built) system, dis is crashing when disassembling /kernel/crypto/amd64/aes, thus:
core '101.dis.4960-1347504528' of 4960: dis /kernel/crypto/amd64/aes 08052ce0 dis_tgt_next_symbol (8066b20, 80692f8, 1000, 0, fed7ca00, 85ad) + 1f 0805459a dis_text_section (8066b20, 80478f8, 80692f8, fee3d135) + 6b 0805308b dis_tgt_section_iter (8066b20, 805452f, 80692f8, 8053d28) + e5 080539f9 dis_file (8047b48, 8047a64, 8054f8f, 8053abf, fef20000, 8047a68) + 126 08053cf0 main (8054d9a, feffb0a4, 8047a58, 80525d3, 2, 8047a64) + 259 080525d3 _start (2, 8047b44, 8047b48, 0, 8047b61, 8047b70) + 83
We get this far:
disassembly for /kernel/crypto/amd64/aes
section .text
.text()
.text: c6 63 63 a5 movb $-0x5b,0x63(%rbx) <0xa5>
.text+0x4: c6 63 63 a5 movb $-0x5b,0x63(%rbx) <0xa5>
.text+0x8: f8 clc
.text+0x9: 7c 7c jl +0x7c <0x1087>
.text+0xb: 84 f8 testb %bh,%al
.text+0xd: 7c 7c jl +0x7c <0x108b>
.text+0xf: 84 ee testb %ch,%dh
.text+0x11: 77 77 ja +0x77 <0x108a>
.text+0x13: 99 cltd
.text+0x14: ee outb (%dx)
.text+0x15: 77 77 ja +0x77 <0x108e>
.text+0x17: 99 cltd
.text+0x18: f6 7b 7b idivb 0x7b(%rbx)
.text+0x1b: 8d f6 leal %esi,%esi
.text+0x1d: 7b 7b jnp +0x7b <0x109a>
.text+0x1f: 8d ff leal %edi,%edi
.text+0x21: f2 f2 0d ff f2 f2 repnz orl $0xdf2f2ff,%eax
0d
zsh: segmentation fault (core dumped) dis /kernel/crypto/amd64/aes
I can provide an 'aes' module and a core, if required.
Updated by Rich Lowe over 9 years ago
This happens when we disassemble 'enc_tab', which is data rather than text (though is in .text).
It is likely that enc_tab should not be text (because it's not), as well as dis not crashing in this case. I suspect that even with dis fixed, it'll be thrown off by the not-code and not actually be useful without enc_tab being moved to rodata.
Updated by Rich Lowe over 9 years ago
This is because we attempt to use the symcache to start walking the symtab in the middle, and do so even if we've never looked up a symbol before. That is if there is stuff at the beginning of .text which is not actually a component of a symbol we care about.
This happens to aes, no doubt, because of the nature of enc_tab:
We have an invalid instruction, without a symtab entry, prior to any valid symbol in .text, so when we hit the invalid insn, we try to progress forward to the beginning of the next symbol (which we can guarantee is on an insn boundary), but because we're prior to any valid symbol, dis_tgt_lookup() has never populated dt_symcache.
Updated by Rich Lowe over 9 years ago
- Status changed from New to Resolved
- % Done changed from 0 to 100
- Tags deleted (
needs-triage)
Resolved in edd4ab0
Updated by Mark Carlton about 5 years ago
I'm using external compilations. Perhaps there could be also a free version of one I bought in 2001. It was available for academic purposes where you can find the codes, decode or find bugs and issues at https://hireessaywriter.org.
Updated by Bruce Bendwick about 3 years ago
This may occur after disassembling 'enc_tab', which is data in .txt
Try doing it again by enabling enc_tab without any text. I've done this with other files on https://elearningways.com and it went very well. This was done for an e-learning program on which the client had done wrong coding and had hit invalid insn. I worked on it at the beginning of a few symbols the problem was resolved.