New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gdb_exception_RETURN_MASK_ERROR #206

Closed
feralgibbons opened this Issue Jan 29, 2018 · 14 comments

Comments

Projects
None yet
5 participants
@feralgibbons
Copy link

feralgibbons commented Jan 29, 2018

Step 0:

Yes, yes, yes

Step 1: Describe your environment

  • Operating System: Linux 4.9.78-v7+

  • Architecture: armv7l
    Byte Order: Little Endian
    CPU(s): 4
    On-line CPU(s) list: 0-3
    Thread(s) per core: 1
    Core(s) per socket: 4
    Socket(s): 1
    Model: 4
    Model name: ARMv7 Processor rev 4 (v7l)
    CPU max MHz: 1200.0000
    CPU min MHz: 600.0000
    BogoMIPS: 38.40
    Flags: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32

  • GDB version (including the Python library version): Debian 7.12-6+b1, Python 2.7/3.7

Step 2: Describe your problem

Attemting to use gef to step (si) through a program unexpectedly aborts
at the end of program with the following error:

 ─────[ threads ]────
[#0] Id 1, Name: "sp_demo", stopped, reason: SINGLE STEP    
─────[ trace ]────
[#0] 0x10064 → Name: exit()
terminate called after throwing an instance of 'gdb_exception_RETURN_MASK_ERROR'
Aborted

This behavior is not observed when using peda or pwndbg, which exit
normally. This behavior is not observed when just running program:

Reading symbols from sp_demo...(no debugging symbols found)...done.
gef➤  run
Starting program: /home/timmy/ARM/code/sp_demo 
[Inferior 1 (process 2528) exited normally]
gef➤  

Steps to reproduce

  1. gdb -q sp_demo
  2. gef> b _start
  3. gef> r
  4. gef> si (until error observed)

Observed Results

See above.

Expected results

 f 0    10068 exit+4
pwndbg> si
[Inferior 1 (process 2545) exited normally]
pwndbg> 

Sample code, sp_demo

@ Test code, stack pointer example 

    .global _start

_start:
   mov r7, #0x30      
   push {r7}          
   mov r7, #0x10      
   pop {r7}           

exit:
    mov r7, #1       
    svc 0

@hugsy

This comment has been minimized.

Copy link
Owner

hugsy commented Jan 29, 2018

I cannot reproduce, it works as expected:

img

Are you using the latest version from master ?
A quick Google points to libreadline related issue. If so, try again with the readline_compat setting to True:

gef➤  gef config gef.readline_compat true
@feralgibbons

This comment has been minimized.

Copy link

feralgibbons commented Jan 29, 2018

Hmmmm. Yes, latest version of master. I saw the libreadline related issue and I just tried your above suggestion, still get the same results. libreadline/libreadline-dev are present. I'll try digging into this more later on this end.

@feralgibbons

This comment has been minimized.

Copy link

feralgibbons commented Jan 31, 2018

Hmm. Using gdb to debug gdb/gef, stepping through sp_demo with si:

gdb --nh --args gdb -q sp_demo

(gdb) r
 gef> b _start
 gef> r
 gef> si
 
(elided)

[#0] 0x10064 -> Name: exit()
terminate calles after throwing an instance of
'gdb_exception_RETURN_MASK_ERROR'

Program received signal SIGABRT, Aborted.
__libc_do_syscall () at
../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:47
47        ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S: No such file
or directory.
(gdb)
@hugsy

This comment has been minimized.

Copy link
Owner

hugsy commented Jan 31, 2018

That's a GDB error, not GEF. This is not even even related to GDB's Python API. You might wanna check forums or ask on their IRC.

@hugsy

This comment has been minimized.

Copy link
Owner

hugsy commented Feb 1, 2018

But when you get to the bottom of this, I would like to document this behavior for the future. So before closing this ticket, can you provide a thorough description of what the issue was, and how you got it fixed?

Cheers.

@Sinkmanu

This comment has been minimized.

Copy link

Sinkmanu commented Feb 3, 2018

Hello @hugsy, I have the same problem and I think that is not a problem of GDB. In my case, when I get a segmentation fault (with GEF) I get "gdb_exception_RETURN_MASK_ERROR", but with GDB (without GEF), i don't get that error. E.g.

GEF:

gef➤  r
Starting program: /home/pi/example/stack1 
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
You entered: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

Program received signal SIGSEGV, Segmentation fault.
[ Legend: Modified register | Code | Heap | Stack | String ]
─────────────────────────────────────────────────────────────────────────────────────────────────────────────[ registers ]────
$r0   : 0x0000003a
$r1   : 0x00000000
$r2   : 0x00000001
$r3   : 0x00000000
$r4   : 0x00010534  →  <__libc_csu_init+0> push {r4,  r5,  r6,  r7,  r8,  r9,  r10,  lr}
$r5   : 0x00000000
$r6   : 0x00010398  →  <_start+0> mov r11,  #0
$r7   : 0x00000000
$r8   : 0x00000000
$r9   : 0x00000000
$r10  : 0x76fff000  →  0x00030f44  →  0x00000000
$r11  : 0x61616161 ("aaaa"?)
$r12  : 0x00000000
$sp   : 0x7effef38  →  "aaaaaaaaaaaaaaaaaaaa"
$lr   : 0x000104ec  →  <vuln+44> nop ; (mov r0,  r0)
$pc   : 0x61616160 ("`aaa"?)
$cpsr : [THUMB fast interrupt overflow CARRY ZERO negative]
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────[ stack ]────
0x7effef38│+0x00: "aaaaaaaaaaaaaaaaaaaa"	 ← $sp
0x7effef3c│+0x04: "aaaaaaaaaaaaaaaa"
0x7effef40│+0x08: "aaaaaaaaaaaa"
0x7effef44│+0x0c: "aaaaaaaa"
0x7effef48│+0x10: "aaaa"
0x7effef4c│+0x14: 0x00010500  →  <main+0> push {r11,  lr}
0x7effef50│+0x18: 0x76ffecf0  →  0x00000000
0x7effef54│+0x1c: 0x7effefe0  →  0xffffffff
────────────────────────────────────────────────────────────────────────────────────────────────────────[ code:arm:thumb ]────
terminate called after throwing an instance of 'gdb_exception_RETURN_MASK_ERROR'
Aborted

GDB (without GEF)

(gdb) r
Starting program: /home/pi/example/stack1
aaaaaaaaaaaaaaaaaaaaaaaaa
You entered: aaaaaaaaaaaaaaaaaaaaaaaaa

Program received signal SIGSEGV, Segmentation fault.
0x61616160 in ?? ()
(gdb) quit
@feralgibbons

This comment has been minimized.

Copy link

feralgibbons commented Feb 3, 2018

@hugsy Yeah no worries. I'll dig into deeper this weekend. What's bothering me is I'm not getting this behavior with gdb anywhere else. :/ But there's nothing in gef that's jumping out at me either. I've also recompiled gdb from source on my system, just in case that was an issue, but still seeing same behavior. I am finding others getting same error w/ different programs, but so far nothing has applied to this situation. In any case, appreciate your quick response. :)

UPDATE Sigh, I'm FOS. Now that I've recompiled from source and re-installed gef I'm getting the same gdb_exception when I reach the end of sp_demo, but a different reason for the failure:

[#0] 0x10064 -> Name: exit()
terminate called after throwing an instance of 'gdb_exception_RETURN_MASK_ERROR'

Program received signal SIGABRT, Aborted.
0x76a56bd6 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6

@Sinkmanu : Just for grins, can you try the following and post the bit where it actually flails here?

gdb --nh --args gdb -q <your_code>
(gdb) r
(gef) r

Also, make sure to try hugsy's suggestion of setting

gef config gef.readline_compat true

before running your code in gef. I still get the same error, but there's a chance this might fix it for you (assuming you haven't already tried this.)

@feralgibbons

This comment has been minimized.

Copy link

feralgibbons commented Feb 3, 2018

@Sinkmanu: Pretty sure that this is indeed a gdb issue.

It looks like perhaps we're both using Pi's? Mine's a 3B, and the latest gdb source I can get from my distro (Kali rolling -- using 'apt-get source gdb') is 7.12.0.20161007. I'm going to try something else here and see if I get any joy, but it's going to take a bit.

@hugsy

This comment has been minimized.

Copy link
Owner

hugsy commented Feb 3, 2018

@Sinkmanu It is a GDB-issued exception, nothing to do with GEF. Also just saying "I have the same problem" is not helpful to fix it. In the future, try to provide more info (your setup, the binary you were testing that on, etc.)

@sashs reported me privately a very same issue not long ago. Apparently the issue would come from GDB triggering this assert() when disassembly an invalid memory area.

I will try to reproduce it, but in any case, there is very little GEF can do about it. This issue should be propagated to the GDB developers.

@Sinkmanu

This comment has been minimized.

Copy link

Sinkmanu commented Feb 3, 2018

Hello @hugsy , I am sorry for not provided my setup. But the setup is the same that @feralgibbons.

processor	: 0
model name	: ARMv7 Processor rev 4 (v7l)
BogoMIPS	: 38.40
Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xd03
CPU revision	: 4

Linux raspberrypi 4.9.59-v7+ #1047 SMP Sun Oct 29 12:19:23 GMT 2017 armv7l GNU/Linux

GNU gdb (Raspbian 7.12-6) 7.12.0.20161007-git

With gef➤ gef config gef.readline_compat true I get the same error.

@feralgibbons , I got the error in this line. Did you try with a old version of GDB?

terminate called after throwing an instance of 'gdb_exception_RETURN_MASK_ERROR'

Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb)

UPDATE I have compiled the last version of GDB (8.1) and It has not that problem.

@sashs

This comment has been minimized.

Copy link
Contributor

sashs commented Feb 3, 2018

Hi. If I recall correctly, it is an issue in older versions of GDB (not the current version). It should be still an issue on Raspberrypi, since GDB 7.12 is the current version in the repositories of raspbian.

@feralgibbons

This comment has been minimized.

Copy link

feralgibbons commented Feb 3, 2018

@hugsy : I've confirmed on my end @sashs comment and @Sinkmanu's result. I believe this issue can be closed.

Original Issue and Mitigation

gdb version 7.12, as distributed w/ Raspbian/Kali rolling (only distro's tested,) throws an exception while disassembling ARM binaries when using gef. This is not a gef problem, this is a gdb problem. gef is just the tool that revealed the gdb dain bramage! (The issue was not observed using vanilla gdb/peda/pwndbg) This issue was first noted when using si to step through a simple ARM assembly program (noted above) when instead of exiting cleanly, gdb's disassembly failed with a SIGABRT and threw an exception:

  gdb_exception_RETURN_MASK_ERROR

This turns out to be a known problem (regression) with gdb, and affects gef users running the ARM platform (Raspberry Pi).

The mitigation is for ARM users to compile gdb from source and run the latest version, 8.1 as of this writing.

gef's README.md should be changed to direct users of the ARM platform, or at least the Raspberry Pi, to ignore their distribution's packaged version of gdb (assuming it is not current) and compile gdb from source.

@hugsy

This comment has been minimized.

Copy link
Owner

hugsy commented Feb 4, 2018

@feralgibbons @sashs @Sinkmanu Thanks for your tests and feedbacks.

I will document this behavior based on @feralgibbons' last comment for others to know about it.

Cheers.

hugsy added a commit that referenced this issue Feb 4, 2018

[issue #206] updated the faq to explain the case of the mysterious gd…
…b_exception_RETURN_MASK_ERROR assert on ARM
@jgfoster

This comment has been minimized.

Copy link

jgfoster commented Dec 6, 2018

For those who find "build gdb from sources" to be insufficient detail, here is what worked for me today:

wget "https://ftp.gnu.org/gnu/gdb/gdb-8.2.tar.gz"
tar -xvzf gdb-8.2.tar.gz
cd gdb-8.2/
./configure --with-python
make
sudo make install

The thing missing from other instructions is that configure needs to be with python. Without it you get #402.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment