classification
Title: stack smash when using ctypes/libffi to access union
Type: crash Stage:
Components: ctypes Versions: Python 2.7
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: Sam.Kerr, amaury.forgeotdarc, belopolsky, doko, meador.inge, seanmccully, wes.kerfoot
Priority: normal Keywords:

Created on 2014-08-08 04:53 by wes.kerfoot, last changed 2018-12-27 00:08 by Sam.Kerr.

Files
File name Uploaded Description Edit
crash.log wes.kerfoot, 2014-08-08 04:53 Contents of C file declaring union and function returning initialized union as well as stack trace/memory map
crash.sh wes.kerfoot, 2014-08-08 21:50 shell script to reproduce stack overflow
Messages (4)
msg225059 - (view) Author: Wesley Kerfoot (wes.kerfoot) Date: 2014-08-08 04:53
Description:
python 2.7.8 fails with a 'stack smashing detected' error and aborts when trying to access a C union using ctypes/libffi

Steps to reproduce:
See the contents of test.c and test.py in the attached file
gcc -c -fpic -Wall -Wextra -pedantic -Wpointer-arith -Werror -std=c99 -O0 ./test.c -o test.o
gcc -shared -o test.so test.o
python2 test.py

Also fails with clang instead of gcc.

OS: Linux frege 3.15.8-1-ARCH #1 SMP PREEMPT Fri Aug 1 08:51:42 CEST 2014 x86_64 GNU/Linux
python2 version: 2.7.8
libffi version (OS wide version): 3.1-2
gcc version: 4.9.1
clang version: 3.4.2

I have tried rebuilding python with the included version of libffi (Arch normally uses a systemwide version).

Here is the PKGBUILD file Arch uses https://projects.archlinux.org/svntogit/packages.git/tree/python2/trunk/PKGBUILD?id=c319b32ada1506cf2bd48acc50649ae77a696c53

I have also reported this bug on their tracker since I am not sure if this is a bug in ctypes or libffi or both: https://bugs.archlinux.org/task/41502
msg225089 - (view) Author: Wesley Kerfoot (wes.kerfoot) Date: 2014-08-08 21:50
Description:
python 2.7.8 fails with a 'stack smashing detected' error and aborts when trying to access a C union using ctypes/libffi

Steps to reproduce: see the attached shell script which reproduces the issue on Ubuntu 13.10 and Arch Linux

Also fails with clang instead of gcc.

OS: Linux frege 3.15.8-1-ARCH #1 SMP PREEMPT Fri Aug 1 08:51:42 CEST 2014 x86_64 GNU/Linux
python2 version: 2.7.8
libffi version (OS wide version): 3.1-2
gcc version: 4.9.1
clang version: 3.4.2

Here is the PKGBUILD file Arch uses https://projects.archlinux.org/svntogit/packages.git/tree/python2/trunk/PKGBUILD?id=c319b32ada1506cf2bd48acc50649ae77a696c53

I have also reported this bug on their tracker since I am not sure if this is a bug in ctypes or libffi or both: https://bugs.archlinux.org/task/41502
msg225234 - (view) Author: Sean McCully (seanmccully) * Date: 2014-08-12 17:44
For what it is worth, I was not able to reproduce, on the current Python 2.7.8 branch and Mac OS X.

./python2
Python 2.7.8+ (2.7:ba90bd01c5f1, Aug 12 2014, 12:21:58)

gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.3.0
Thread model: posix

Version:	5.1.1 (5B1008)
  Location:	/Applications/Xcode.app
  Applications:
  Xcode:	5.1.1 (5085)
  Instruments:	5.1.1 (55045)
  SDKs:
  OS X:
  10.8:	(12F37)
  10.9:	(13C64)
  iOS:
  7.1:	(11D167)
  iOS Simulator:
  7.1:	(11D167)


python2 test.py
True
msg332568 - (view) Author: Sam Kerr (Sam.Kerr) Date: 2018-12-27 00:08
I was also able to get the stack smashing behavior with the following:
OS: Linux slaptop 4.19.12-arch1-1-ARCH #1 SMP PREEMPT Fri Dec 21 13:56:54 UTC 2018 x86_64 GNU/Linux
GCC: gcc (GCC) 8.2.1 20181127

I was able to track down the issue into the src/x86/ffi64.c file inside libffi. Because more than 4 (the #define'd MAX_CLASSES value in libffi) items were passed, libffi writes outside an array boundary, which is what causes the stack smashing. 

I forked libffi and added an assert to prove this is what is happening. You can find it at https://github.com/stkerr/libffi/commit/80bca6647702ffd846c655be14d8306ef24ca2dd. Just as a quick test, I tried to increase the MAX_CLASSES value to 40, which is far more than the 9 in the crashing example. I'm 99% positive changing the MAX_CLASSES magic value isn't the right way to solve this issue, but it may give a hint on the proper way to address it.

I'm not sure at this point if this behavior is something for libffi to fix or how Python calls libffi though. I'll keep looking, but hopefully this helps someone else make some progress.
History
Date User Action Args
2018-12-27 00:08:16Sam.Kerrsetnosy: + Sam.Kerr
messages: + msg332568
2014-08-12 17:44:50seanmccullysetnosy: + seanmccully
messages: + msg225234
2014-08-10 15:59:13pitrousetnosy: + doko
2014-08-08 21:50:09wes.kerfootsetfiles: + crash.sh

messages: + msg225089
2014-08-08 04:53:59wes.kerfootcreate