Segfault in _PyObject_GenericGetAttrWithDict

[gilado]

BPO	35298
Nosy	@gilado

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2018-11-23.00:14:54.018>
labels = ['interpreter-core', 'type-crash']
title = 'Segfault in _PyObject_GenericGetAttrWithDict'
updated_at = <Date 2018-11-23.00:14:54.018>
user = 'https://github.com/gilado'

bugs.python.org fields:

activity = <Date 2018-11-23.00:14:54.018>
actor = 'gilado'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2018-11-23.00:14:54.018>
creator = 'gilado'
dependencies = []
files = []
hgrepos = []
issue_num = 35298
keywords = []
message_count = 1.0
messages = ['330289']
nosy_count = 1.0
nosy_names = ['gilado']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'crash'
url = 'https://bugs.python.org/issue35298'
versions = ['Python 3.6']

[gilado]

Running pulseeffects, it crashes occasionally. I have yet to find a cause, it just happens.
I decided to run it under gdb to catch the crash. It worked for a few days before crashing.

$ GDK_DPI_SCALE=0.6 gdb -args /usr/bin/python3 /usr/bin/pulseeffects 

gdb: Symbol `acs_map' has different size in shared object, consider re-linking
GNU gdb (GDB) 7.8-1pclos2014 (PCLinuxOS release 2014)
...
...
13:57:26.125 - PulseEffects - CRITICAL - PM - context operation failed!
13:57:29.779 - PulseEffects - CRITICAL - PM - context operation failed!
13:57:30.391 - PulseEffects - CRITICAL - PM - context operation failed!
[New LWP 27696]

Program received signal SIGSEGV, Segmentation fault.
[Switching to LWP 27696]
0x00007ffff73bcae6 in ?? () from /lib64/libc.so.6
(gdb) bt
#0 0x00007ffff73bcae6 in () at /lib64/libc.so.6
#1 0x00007ffff29f8e08 in ()
at /usr/lib64/python3.6/lib-dynload/_ctypes.cpython-36m-x86_64-linux-gnu.so
#2 0x00007ffff79baf1e in _PyObject_GenericGetAttrWithDict ()
at /usr/lib64/libpython3.6m.so.1.0
#3 0x00007ffff7a2b6b0 in _PyEval_EvalFrameDefault ()
at /usr/lib64/libpython3.6m.so.1.0
#4 0x00007ffff7a271df in () at /usr/lib64/libpython3.6m.so.1.0
#5 0x00007ffff7a2fce0 in _PyFunction_FastCallDict ()
at /usr/lib64/libpython3.6m.so.1.0
#6 0x00007ffff79719fe in _PyObject_FastCallDict ()
at /usr/lib64/libpython3.6m.so.1.0
#7 0x00007ffff7971c0d in _PyObject_Call_Prepend ()
at /usr/lib64/libpython3.6m.so.1.0
#8 0x00007ffff79717c8 in PyObject_Call () at /usr/lib64/libpython3.6m.so.1.0
#9 0x00007ffff29f433d in ()
at /usr/lib64/python3.6/lib-dynload/_ctypes.cpython-36m-x86_64-linux-gnu.so
#10 0x00007ffff3f73dcf in ffi_closure_unix64_inner () at /usr/lib64/libffi.so.6
#11 0x00007ffff3f74148 in ffi_closure_unix64 () at /usr/lib64/libffi.so.6
#12 0x00007fffde2abaf5 in () at /usr/lib64/libpulse.so.0
#13 0x00007fffddf27ce1 in () at /usr/lib64/pulseaudio/libpulsecommon-12.2.so
#14 0x00007fffddf28033 in pa_pdispatch_run ()
at /usr/lib64/pulseaudio/libpulsecommon-12.2.so
#15 0x00007fffde2aaa9e in () at /usr/lib64/libpulse.so.0
#16 0x00007fffddf2ab4f in () at /usr/lib64/pulseaudio/libpulsecommon-12.2.so
#17 0x00007fffddf2d5db in () at /usr/lib64/pulseaudio/libpulsecommon-12.2.so
#18 0x00007fffddf2d979 in () at /usr/lib64/pulseaudio/libpulsecommon-12.2.so
#19 0x00007fffddf2e1df in () at /usr/lib64/pulseaudio/libpulsecommon-12.2.so
#20 0x00007fffde2bea58 in pa_mainloop_dispatch () at /usr/lib64/libpulse.so.0
#21 0x00007fffde2bee1e in pa_mainloop_iterate () at /usr/lib64/libpulse.so.0
#22 0x00007fffde2beea0 in pa_mainloop_run () at /usr/lib64/libpulse.so.0
#23 0x00007fffde2cc786 in () at /usr/lib64/libpulse.so.0
#24 0x00007fffddf3db48 in () at /usr/lib64/pulseaudio/libpulsecommon-12.2.so
#25 0x00007ffff76ed62e in () at /lib64/libpthread.so.0
#26 0x00007ffff7421def in clone () at /lib64/libc.so.6
(gdb)

Seems to be a python bug not validating a data pointer.

A similar bug was fixed here https://bugs.python.org/issue12149

reviewing the code https://github.com/python/cpython/blob/master/Objects/object.c

I think line 981 mentioned in the bug description is now line 1235

f = descr->ob_type->tp_descr_get;

Which now is protected inside an if (descr != NULL). So they fixed it here.
Further just below that both 'f' and 'descr' are used like this

if (f != NULL && PyDescr_IsData(descr)) {
res = f(descr, obj, (PyObject *)obj->ob_type);

The problem now seem to be further below (line 1279) where the code is

if (f != NULL) {
res = f(descr, obj, (PyObject *)Py_TYPE(obj));

The problem is that they forget to check that descr is valid.

[kumaraditya303]

Closing as Python 3.6 is not supported.