Package: python3-sip
Version: 4.19.14+dfsg-2
Severity: important
Tags: upstream
Dear Maintainer,
Sometimes during startup (depend on python code, comment line can affect this)
my software
crashes with segmentation fault in python-sip.
Gdb backtrace:
Thread 1 "python" received signal SIGSEGV, Segmentation fault.
add_object (om=0x7ffff6cfafa0 <cppPyMap>, addr=<optimized out>,
val=0x7fffb97eff28) at ./siplib/objmap.c:286
286 ./siplib/objmap.c: Нет такого файла или каталога.
(gdb) bt
#0 0x00007ffff6ced648 in add_object (om=0x7ffff6cfafa0 <cppPyMap>,
addr=<optimized out>, val=0x7fffb97eff28) at ./siplib/objmap.c:286
#1 0x00007ffff6cedb1b in sipOMAddObject (om=om@entry=0x7ffff6cfafa0
<cppPyMap>, val=val@entry=0x7fffb97eff28) at ./siplib/objmap.c:162
#2 0x00007ffff6ceb562 in sipSimpleWrapper_init (self=0x7fffb97eff28, args=
(<Grid(_layout=<QGridLayout at remote 0x7fffb97ef640>, ncol=3, n=10) at
remote 0x7fffb97ef5a8>,), kwds=0x0) at ./siplib/siplib.c:10646
#3 0x00005555556bf148 in wrap_init
(kwds=<optimized out>, wrapped=0x7ffff6ceb300 <sipSimpleWrapper_init>,
args=(<Grid(_layout=<QGridLayout at remote 0x7fffb97ef640>, ncol=3, n=10) at
remote 0x7fffb97ef5a8>,), self=<optimized out>) at ../Objects/typeobject.c:4928
#4 0x00005555556bf148 in wrapper_call
(wp=wp@entry=<method-wrapper '__init__' of Label object at 0x7fffb97eff28>,
args=args@entry=(<Grid(_layout=<QGridLayout at remote 0x7fffb97ef640>, ncol=3,
n=10) at remote 0x7fffb97ef5a8>,), kwds=<optimized out>) at
../Objects/descrobject.c:1035
#5 0x000055555564ebf7 in PyObject_Call
(kw=0x0, arg=(<Grid(_layout=<QGridLayout at remote 0x7fffb97ef640>, ncol=3,
n=10) at remote 0x7fffb97ef5a8>,), func=<method-wrapper '__init__' of Label
object at 0x7fffb97eff28>) at ../Objects/abstract.c:2544
#6 0x000055555564ebf7 in PyEval_CallObjectWithKeywords
(func=<method-wrapper '__init__' of Label object at 0x7fffb97eff28>,
arg=(<Grid(_layout=<QGridLayout at remote 0x7fffb97ef640>, ncol=3, n=10) at
remote 0x7fffb97ef5a8>,), kw=<optimized out>) at ../Python/ceval.c:4245
#7 0x00005555556f1ffb in wrapperdescr_call
(descr=descr@entry=0x7ffff7585d20, args=(<Grid(_layout=<QGridLayout at
remote 0x7fffb97ef640>, ncol=3, n=10) at remote 0x7fffb97ef5a8>,),
kwds=<optimized out>) at ../Objects/descrobject.c:343
#8 0x0000555555626883 in PyObject_Call (func=<wrapper_descriptor at remote
0x7ffff7585d20>, arg=<optimized out>, kw=<optimized out>)
at ../Objects/abstract.c:2544
#9 0x0000555555647212 in ext_do_call
(nk=<optimized out>, na=<optimized out>, flags=<optimized out>,
pp_stack=0x7fffffffb750, func=<wrapper_descriptor at remote 0x7ffff7585d20>) at
../Python/ceval.c:4690
#10 0x0000555555647212 in PyEval_EvalFrameEx (f=<optimized out>,
throwflag=<optimized out>) at ../Python/ceval.c:3052
Looks the problem in add_object in siplib/objmap.cpp
There two lines:
/*
* We are removing it from the map here. However, note
* that we first have to call the destructor before marking
* it as not being in the map, as the destructor itself
* might end up trying to remove the wrapper and its
* aliases from the map. In that case, if the wrapper is
* already marked as not in the map, the removal will just
* return early, leaving any potential aliases as stale
* entries in the map. If we later try to wrap a different
* object at the same address, we end up retrieving the
* stale alias entry from the object map, triggering a
* use-after-free when accessing its C++ object.
*/
sip_api_instance_destroyed(sw);
sipSetNotInMap(sw);
It seems first line frees sw, and second line can't write memory by sw.
python-sip 4.16.4+dfsg-1 (debian 8), was ok, but in 4.19.14+dfsg-2 source
changes:
- /* We are removing it from the map here. */
+ /*
+ * We are removing it from the map here. However, note
+ * that we first have to call the destructor before marking
+ * it as not being in the map, as the destructor itself
+ * might end up trying to remove the wrapper and its
+ * aliases from the map. In that case, if the wrapper is
+ * already marked as not in the map, the removal will just
+ * return early, leaving any potential aliases as stale
+ * entries in the map. If we later try to wrap a different
+ * object at the same address, we end up retrieving the
+ * stale alias entry from the object map, triggering a
+ * use-after-free when accessing its C++ object.
+ */
+ sip_api_instance_destroyed(sw);
sipSetNotInMap(sw);
- sip_api_common_dtor(sw);
May be it was not so good change ? Latest source is same as 4.19.14+dfsg-2,
so I expect the bug exists until now.
-- System Information:
Debian Release: 10.11
APT prefers oldstable-updates
APT policy: (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500,
'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-18-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8),
LANGUAGE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages python3-sip depends on:
ii libc6 2.28-10
ii libgcc1 1:8.3.0-6
ii libstdc++6 8.3.0-6
ii python3 3.7.3-1
python3-sip recommends no packages.
python3-sip suggests no packages.
-- no debconf information
