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