Possible buffer overflow in libps6000 on OS X

Post your C and C++ discussions here
Post Reply
caladan
Newbie
Posts: 0
Joined: Wed Mar 18, 2015 1:28 pm

Possible buffer overflow in libps6000 on OS X

Post by caladan »

Hi,

First I'd like to say that I'm impressed because the library seems to be well written and well documented - it also works in the same way under both Linux and Mac OS X. But...

I have run into some problems and I guess it's better to ask than to guess what could be wrong, so here it goes...

I've been tasked at work with creating a simple software that sets up a PS6402A and reads back some values after it has been triggered. The code I wrote seems to work but occasionally I get an error at the exit stating that an area of memory was used after being freed.

I've tried tracing it but it always ends up poiting to the internals of ps6000OpenUnit() and there's way to much inside to be able to tell what's wrong.

That's why I wrote a simple test case that makes this problem appear all the time.
Operating system: Mac OS X 10.10.2 on MacBook Pro 15''.
Compiler (supplied by Apple): Apple LLVM version 6.0 (LLVM 3.5SVN),
Compiler (used to force the error): clang 3.7 from Mac Ports

Code:

Code: Select all

#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#ifndef PICO_STATUS
#include 
#endif

int main()
{
  int16_t handle = 0;
  PICO_STATUS status = ps6000OpenUnit(&handle, NULL);
  if (status != PICO_OK)
    return status;

  ps6000CloseUnit(handle);
  return 0;
}
Command used to compile:

Code: Select all

clang-mp-3.7 -g -I[...] test.c -o test -L[...] -lps6000 -fsanitize=address
The last part forces memory sanitizer to be included.

Result (already trimmed):
[...]

Code: Select all

==1571==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61100000832f at pc 0x000106e2e54c bp 0x7fff58dea630 sp 0x7fff58de9db8
WRITE of size 9 at 0x61100000832f thread T0
    #0 0x106e2e54b  (/opt/local/libexec/llvm-3.7/lib/clang/3.7/lib/darwin/libclang_rt.asan_osx_dynamic.dylib+0x1554b)
    #1 0x106e2f071  (/opt/local/libexec/llvm-3.7/lib/clang/3.7/lib/darwin/libclang_rt.asan_osx_dynamic.dylib+0x16071)
    #2 0x107b52557  (/Users/caladan/PS6000/libps6000.2.dylib+0x7557)
    #3 0x107b4f0f5  (/Users/caladan/PS6000/libps6000.2.dylib+0x40f5)
    #4 0x107b52e13  (/Users/caladan/PS6000/libps6000.2.dylib+0x7e13)
    #5 0x106e13b6c  (/Users/caladan/PS6000/./test+0x100000b6c)
    #6 0x7fff8e6a35c8  (/usr/lib/system/libdyld.dylib+0x35c8)
    #7 0x0  ()
[...]

Did anybody see a behaviour like this before? I'm ready to provide more details if needed.

PS. Does ps6000UnitOpen have to accept int8_t* as the second parameter? I have to cast all my const char*'s to suppress compilier's compaints...

Cheers,
Caladan

Hitesh

Re: Possible buffer overflow in libps6000 on OS X

Post by Hitesh »

Hi Caladan,

Does this happen on the Linux version?

What happens if you specify the serial number of the device instead of passing NULL to the ps6000OpenUnit call?

Regards,

caladan
Newbie
Posts: 0
Joined: Wed Mar 18, 2015 1:28 pm

Re: Possible buffer overflow in libps6000 on OS X

Post by caladan »

Hi,

I think I managed to trigger it on Linux but can't give you definite answer right now as I'm not at work. I will try to reproduce it and give you more details as soon as I can.

Cheers,
Caladan

caladan
Newbie
Posts: 0
Joined: Wed Mar 18, 2015 1:28 pm

Re: Possible buffer overflow in libps6000 on OS X

Post by caladan »

I can't replicate right now but it may be just because I'm now running SLC6 (based on CentOS6) which has a really old version of clang.

It makes no difference if I provide the serial or not.

Post Reply