Bug #3194

dis crashes disassembling aes

Added by Rich Lowe over 8 years ago. Updated about 1 year ago.

cmd - userland programs
Start date:
Due date:
% Done:


Estimated time:
Gerrit CR:


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: 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
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 7 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 7 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 7 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 almost 3 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


Updated by Bruce Bendwick about 1 year 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 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.

Also available in: Atom PDF