malisal / bfdpie Goto Github PK

It looks like there is an issue with handling vmas > INT_MAX due to the arguments used with PyArg.
This example can reproduce the problem on my 64-bit machine with gcc 7.30, python 3.6.5, and bfdpie 0.1.13 from pypi:

import bfdpie

bfdpie.Binary().disassemble_simple(b"\x90", bfdpie.ARCH_X86_64, 0x7fffffff)
bfdpie.Binary().disassemble_simple(b"\x90", bfdpie.ARCH_X86_64, 0x80000000)

which gives the following output:

nop
Traceback (most recent call last):
  File "./bfdtest.py", line 6, in <module>
    bfdpie.Binary().disassemble_simple(b"\x90", bfdpie.ARCH_X86_64, 0x80000000)
  File "/usr/local/lib/python3.6/dist-packages/bfdpie/bfdpie.py", line 336, in disassemble_simple
    for i in self.disassemble(data, arch, vma):
  File "/usr/local/lib/python3.6/dist-packages/bfdpie/bfdpie.py", line 318, in disassemble
    ops = _bfd.disassemble_bytes(self._ptr, arch_id, data, vma)
TypeError: Invalid parameter(s)

I believe this is due to this code in the function pybfd_disassemble_bytes in bfdpie.c:

// ...
size_t vma;
if(PyArg_ParseTuple(args, "nis#i", &abfd, &arch_num, &data, &data_len, &vma))
{
   // ...
}
else
{
  PyErr_SetString(PyExc_TypeError, "Invalid parameter(s)");
}
// ...

Where according to this page, the i format parses the value assigned to vma as an int rather than as a size_t. This issue can be fixed by changing the type of vma to unsigned long long and using the format specifier K.

Hi,

There is a memory leak in this module, but I don't know exactly where.

I've made a script that would use just two attributes of the library:

1. The constructor
2. The "symbols" instance attribute

After inspecting thousands of binaries, python process was at 10GB of allocated memory.

I'm running Python 3.6.1 (64-bit) on CentOS 7.1.1503 and using the latest available version on pypi. Compiler is gcc 4.8.3.