Test and Measurement Forum

Possible buffer overflow in libps6000 on OS X

Post your C and C++ discussions here

Possible buffer overflow in libps6000 on OS X

Postby caladan » Thu Mar 19, 2015 1:40 pm

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 <sys/types.h>
#include <string.h>
#include <termios.h>
#include <sys/ioctl.h>
#include <sys/types.h>
#include <unistd.h>
#include <stdlib.h>

#include <libps6000-1.4/ps6000Api.h>
#ifndef PICO_STATUS
#include <libps6000-1.4/PicoStatus.h>
#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  (<unknown module>)

[...]

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
caladan
Newbie
 
Posts: 0
Joined: Wed Mar 18, 2015 1:28 pm

Re: Possible buffer overflow in libps6000 on OS X

Postby Hitesh » Wed Apr 01, 2015 3:02 pm

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,
Hitesh

Technical Specialist
Pico Technology
Hitesh
Site Admin
Site Admin
 
Posts: 2009
Joined: Tue May 31, 2011 3:43 pm
Location: St. Neots, Cambridgeshire

Re: Possible buffer overflow in libps6000 on OS X

Postby caladan » Mon Apr 06, 2015 10:11 am

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

Postby caladan » Thu Apr 09, 2015 4:10 pm

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.
caladan
Newbie
 
Posts: 0
Joined: Wed Mar 18, 2015 1:28 pm


Return to C and C++

Who is online

Users browsing this forum: No registered users and 0 guests