Binary garbage in afij output, possibly stale pointer in func->cc

[oebeling]

While scripting radare2 with r2pipe, I noticed that the output of the afij command sometimes randomly fails to parse as valid UTF-8/JSON. Digging a bit deeper shows that this is due to binary garbage in the "calltype" field. The underlying value is the cc member of the r_anal_type_function_t struct, which comes from calls to functions of the form r_anal_cc_XXXX, which in turn get their return value from sdb using sdb_const_get. Is the const char* returned from sdb_const_get guaranteed to be live until the end of the r2 instance? If not, r_anal_cc_XXX functions should probably take copies of the underlying string.

The following shows a semi-reproducible test case (reproduces ~50% of the time):

$ r2 /usr/bin/r2
 -- TIRED OF WAITING
[0x00002e00]> aaaa; s sym.main
[x] Analyze all flags starting with sym. and entry0 (aa)
[x] Analyze len bytes of instructions for references (aar)
[x] Analyze function calls (aac)
[x] Emulate code to find computed references (aae)
[x] Analyze consecutive function (aat)
[Warning null var in fcn.0x36e4.b.1.-32ctions (afta)unc.* functions (aan)
...
[x] Type matching analysis for all functions (afta)
[x] Type matching analysis for all functions (afta)
[0x00003b12]> #!pipe python -c 'import r2pipe; r=r2pipe.open(); print r.cmd("ifaj;afij")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/.../python2.7/site-packages/r2pipe/__init__.py", line 242, in cmd
    return self._cmd(cmd).strip()
  File "/.../python2.7/site-packages/r2pipe/__init__.py", line 200, in _cmd_pipe
    return out.decode('utf-8')
  File "/.../python2.7/encodings/utf_8.py", line 16, in decode
    return codecs.utf_8_decode(input, errors, True)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xbb in position 50374: invalid start byte
[0x00003b12]>

r2pipe isn't necessary to repro, but has the advantage of giving you a clear error message. Simply running similar commands from the CLI shows the binary garbage in the call-convention field:

[0x00003b12]> afi
#
offset: 0x00003b12
name: main
size: 622
realsz: 622
stackframe: 1608
call-convention: `X���U

[Maijin]

Hello,

Ensure you are using radare2 from git, if you're unsure paste output of r2 -v here. To install radare2 from git, first uninstall your version of radare2 and clean your distro. Then use git clone https://github.com/radare/radare2 && cd radare2 && ./sys/install.sh, verify your version and check if there is no error using r2 -v.

[oebeling]

I should've included the version information in the OP - I did pull from git and confirm just before filing this issue.

Just re-confirmed the behavior with this version:

 radare2 1.5.0-git 14642 @ linux-x86-64 git.1.4.0-103-g905cb24
 commit: 905cb2485164800796d212d3cdfd2bd3e552e8eb build: 2017-05-04__09:24:43

[radare]

cant reproduce, and valgrind/asan says nothing about undefined behaviour, so i cant say where a bug in ij bug is.. and iirc i fixed this bug this week already.

but i agree on you that this calltype is no longer persistent, it was const char* until oddcoder rewrote the whole thing to allow dynamic setup of calling conventions. so if that changes the pointer will no longer be valid.

my last commit should fix this. pls confirm

On 04 May 2017, at 10:31, Otto Ebeling notifications@github.com wrote:

I should've included the version information in the OP - I did pull from git and confirm just before filing this issue.

Just re-confirmed the behavior with this version:

radare2 1.5.0-git 14642 @ linux-x86-64 git.1.4.0-103-g905cb24 commit: 905cb2485164800796d212d3cdfd2bd3e552e8eb build: 2017-05-04__09:24:43 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/radare/radare2/issues/7404#issuecomment-299125740, or mute the thread https://github.com/notifications/unsubscribe-auth/AA3-li8zCTzPQpfFRNwGz-iS3mLsHd-oks5r2YzjgaJpZM4NOvt-.

[oebeling]

Unable to reproduce anymore, so 0ac3477662fc7b828f0fb651e7f3f2b61ba80d0b appears to indeed have fixed it. Thanks a lot for the fast resolution :)