The 2nd pam test in a single Python test case seems to cause a segfault. ==2891729== Invalid write of size 8 ==2891729== at 0x13ADD613: memcpy (string_fortified.h:34) ==2891729== by 0x13ADD613: pamtest_simple_conv (libpamtest.c:300) ==2891729== by 0x14B87585: send_info_msg (pam_fprintd.c:81) ==2891729== by 0x14B876EF: verify_finger_selected (pam_fprintd.c:260) ==2891729== by 0x15759AA7: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.2) ==2891729== by 0x157592A3: ffi_call (in /usr/lib64/libffi.so.6.0.2) ==2891729== by 0x1552F24C: g_cclosure_marshal_generic (in /usr/lib64/libgobject-2.0.so.0.6200.4) ==2891729== by 0x154FCEC2: ??? (in /usr/lib64/libdbus-glib-1.so.2.3.4) ==2891729== by 0x1552E741: g_closure_invoke (in /usr/lib64/libgobject-2.0.so.0.6200.4) ==2891729== by 0x15542603: ??? (in /usr/lib64/libgobject-2.0.so.0.6200.4) ==2891729== by 0x1554B3AD: g_signal_emit_valist (in /usr/lib64/libgobject-2.0.so.0.6200.4) ==2891729== by 0x1554B9D2: g_signal_emit (in /usr/lib64/libgobject-2.0.so.0.6200.4) ==2891729== by 0x154FD9D2: ??? (in /usr/lib64/libdbus-glib-1.so.2.3.4) ==2891729== Address 0x0 is not stack'd, malloc'd or (recently) free'd
I think that the problem probably is that the Python code expects each input (whether echo on or echo off input), to generate at most one info or error output. This patch fixes it for my usage: diff --git a/src/python/pypamtest.c b/src/python/pypamtest.c index 4147364..8de05e9 100644 --- a/src/python/pypamtest.c +++ b/src/python/pypamtest.c @@ -852,8 +852,8 @@ static int fill_conv_data(PyObject *py_echo_off, return ENOMEM; } - conv_data->out_info = new_conv_list(conv_count); - conv_data->out_err = new_conv_list(conv_count); + conv_data->out_info = new_conv_list(PAM_CONV_MSG_MAX); + conv_data->out_err = new_conv_list(PAM_CONV_MSG_MAX); if (conv_data->out_info == NULL || conv_data->out_err == NULL) { free_conv_data(conv_data); return ENOMEM;
I think you're right. I don't have time this week, but my plan for next week was to add Gitlab CI support for pam_wrapper. Do you have a test to reproduce this? It would be great to have on in pam_wrapper so that we don't regress :-)
(In reply to Andreas Schneider from comment #2) I can certainly write a patch and a test, but where's that gitlab repo for pam_wrapper? I couldn't find it, and didn't fancy subscribing to another mailing-list to send patches.
Created attachment 15748 [details] crasher fix git-am formatted patches. Revert "python: Fix crash when the PAM module outputs too much data" and check that the tests crash.
Patch is now in an MR at: https://gitlab.com/cwrap/pam_wrapper/-/merge_requests/2
Fixed with pam_wrapper-1.1.2.