pusha assembly language instruction

Question

I am having a core dump which stack is corrupted. I try to disassemble it and found the following plz help me to anaylyse it ..

(gdb) bt
#0  0x55a63c98 in ?? ()
#1  0x00000000 in ?? ()

(gdb) disassemble 0x55a63c90 0x55a63ca8

Dump of assembler code from 0x55a63c90 to 0x55a63ca8:

0x55a63c90:     add    %cl,%dh

0x55a63c92:     cmpsb  %es:(%edi),%ds:(%esi)

0x55a63c93:     push   %ebp

0x55a63c94:     add    %al,(%eax)

0x55a63c96:     add    %al,(%eax)

**0x55a63c98:     pusha**

0x55a63c99:     lret   $0x9

0x55a63c9c:     subb   $0x56,0xd005598(%ebp)

0x55a63ca3:     push   %ebp

0x55a63ca4:     jo     0x55a63cc5

0x55a63ca6:     sahf

0x55a63ca7:     push   %ebp

End of assembler dump.
(gdb) q

Can this pusha instruction can lead to a core dump ?

Answer 1

pusha can only lead to a core dump if stack overflow occurs at that point. This instruction pushes all the registers values onto the stack and that could lead to an overflow. However the root of the problem is likely elsewhere - most likely the call stack is too deep at that point and pusha just happens to cause such consequences because it is executed in such conditions.

Answer 2

check if you see aligned disassemble code:

x/i $eip

Also show registers values:

i r

Answer 3

No^*, all pusha does is push all the general purpose registers to the stack, including the stack pointer! What is causing the core dump is the instruction after the pusha, lret, which is a long return with stack pop. The return address is the most recent value pushed to the stack, which in this case will be whatever was in esi:edi (since they are the last values to be pushed by the pusha instruction), and that's likely to point to somewhere random.

* Unless you run out of stack space.

Answer 4

Absolutely. PUSHA followed by RET is never correct, the return address will be junk. Seeing ADD AL,[EAX] in your disassembly is another dead give away, that's the disassembly for 0.

In other words: you are disassembling data, not code. Your program bombed because it was executing data. The classic way that happens is corrupting a stack frame with a buffer overflow. When the function returns it pops an invalid return address from the corrupted stack and jumps into never never land. Not getting a seg fault is very unlucky.

Hard to debug, the stack trace is junked. You'll need to set a breakpoint at the last known good code address and start single stepping. The last good function you stepped into just before it bombs is typically the trouble maker.