Bug 15078 - samba-tool domain join segfault when joining a samba ad domain
Summary: samba-tool domain join segfault when joining a samba ad domain
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: Tools (show other bugs)
Version: 4.16.0
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
Depends on:
Reported: 2022-05-25 09:13 UTC by Michael Tokarev
Modified: 2022-05-25 11:40 UTC (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Michael Tokarev 2022-05-25 09:13:28 UTC
There's a segfault possible in samba-tool domain join|leave due to incorrect usage of "p" attribute of PyArg_ParseTupleAndKeywords() function.

$ samba-tool domain join $DOMAIN MEMBER -U $USERNAME
BACKTRACE: 36 stack frames:
 #0 /lib/x86_64-linux-gnu/libsamba-util.so.0(log_stack_trace+0x30) [0x7ffff70510f0]
 #1 /lib/x86_64-linux-gnu/libsamba-util.so.0(smb_panic+0x9) [0x7ffff7051339]
 #2 /lib/x86_64-linux-gnu/libsamba-util.so.0(+0xf3d1) [0x7ffff70513d1]
 #3 /lib/x86_64-linux-gnu/libpthread.so.0(+0x14140) [0x7ffff7fad140]
 #4 /usr/lib/python3/dist-packages/samba/net_s3.cpython-39-x86_64-linux-gnu.so(+0x7558) [0x7ffff221c558]
 #5 /usr/bin/python3() [0x53f350]
 #6 /usr/bin/python3(_PyObject_MakeTpCall+0x39b) [0x51d89b]
 #7 /usr/bin/python3(_PyEval_EvalFrameDefault+0x5f7f) [0x517a0f]
 #8 /usr/bin/python3() [0x5106ed]
 #9 /usr/bin/python3(_PyFunction_Vectorcall+0x361) [0x528d21]
 #10 /usr/bin/python3() [0x53bcfb]
 #11 /usr/bin/python3(PyObject_Call+0xc1) [0x53c361]
 #12 /usr/bin/python3(_PyEval_EvalFrameDefault+0x23fb) [0x513e8b]
 #13 /usr/bin/python3() [0x5106ed]
 #14 /usr/bin/python3(_PyFunction_Vectorcall+0x361) [0x528d21]
 #15 /usr/bin/python3() [0x53be7e]
 #16 /usr/bin/python3(_PyEval_EvalFrameDefault+0x23fb) [0x513e8b]
 #17 /usr/bin/python3() [0x5106ed]
 #18 /usr/bin/python3(_PyFunction_Vectorcall+0x361) [0x528d21]
 #19 /usr/bin/python3() [0x53be7e]
 #20 /usr/bin/python3(_PyEval_EvalFrameDefault+0x23fb) [0x513e8b]
 #21 /usr/bin/python3() [0x5106ed]
 #22 /usr/bin/python3(_PyFunction_Vectorcall+0x361) [0x528d21]
 #23 /usr/bin/python3() [0x53be7e]
 #24 /usr/bin/python3(_PyEval_EvalFrameDefault+0x23fb) [0x513e8b]
 #25 /usr/bin/python3() [0x5106ed]
 #26 /usr/bin/python3(_PyEval_EvalCodeWithName+0x47) [0x510497]
 #27 /usr/bin/python3(PyEval_EvalCode+0x23) [0x5f5be3]
 #28 /usr/bin/python3() [0x619de7]
 #29 /usr/bin/python3() [0x615610]
 #30 /usr/bin/python3() [0x619d79]
 #31 /usr/bin/python3(PyRun_SimpleFileExFlags+0x196) [0x619816]
 #32 /usr/bin/python3(Py_RunMain+0x2b3) [0x60d4e3]
 #33 /usr/bin/python3(Py_BytesMain+0x29) [0x5ea6e9]
 #34 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea) [0x7ffff7c5dd0a]
 #35 /usr/bin/python3(_start+0x2a) [0x5ea5ea]

(it doesn't even ask for a password for the $USERNAME).  This happens in py_net_join_member() and depends on the stack layout (so it is dependent on the compiler used and on the endianness of the code).

In my testcase (x86-64 arch, gcc-9, debian stable "bullseye" environment), compiler puts struct libnet_JoinCtx *r variable right on the next address after uint8_t no_dns_updates variable.  And this variable (no_dns_updates) is used as an argument for PyArg_ParseTupleAndKeywords(), in place of "p" parameter, - which, according to the python documentation, expects parameter of type int.  So after PyArg_ParseTupleAndKeywords() return, r variable becomes NULL, and next we immediately see a segfault because when trying to access various members of the structure pointed to by r.

The same issue happens with other similar usages of this "p" argument in this file - there are 4 of them, but unfortunately, in other places the result isn't an immediate crash but garbage in other variables which may or may not be okay, again, depending on the memory layout.

Even this very place actually does not crash on debian testing "bookworm" system with gcc-12 and a different python version, - but again, this is not because the bug does not exist but because it garbles other data in some other way.

This is fixed by the upstream commit 976326fa2b6423ac5866af682605cf7584e4991a
Comment 1 Andrew Bartlett 2022-05-25 11:40:21 UTC
Reopening for a backport to 4.16 and 4.15