Created attachment 238390 [details] Contains xscreensaver.log (generated during auth crash), and .xscreensaver settings. xscreensaver 6.04, installed either from packages or by building from source in ports, crashes during authentication. When this happens, xscreensaver does not unlock (good!), and core is dumped to ~/xscreensaver-auth.core. I've attached a tarball of the log and config, and can generate a coredump if required (as a different user, as the generated coredump seems to contain my password). Repro steps: 1. install xscreensaver with: sudo pkg install xscreensaver 2. run xscreensaver with: xscreensaver --log xscreensaver.log 3. lock the screen with: xscreensaver-command -lock 4. attempt to unlock the screen with my password 5. expected: the screen unlocks 6. actual: the screen doesn't unlock
There's an even easier repo process - build the xscreensaver port then: 1. cd /usr/ports/x11/xscreensaver/work/xscreensaver-6.04 2. ./driver/xscreensaver-auth --dpy :0.0 Enter your password, then press Enter. If you entered your password incorrectly, you get an "Authentication failed!" message. If you entered your password correctly, you get a segfault.
(In reply to Duncan Bayne from comment #1) Hi Duncan, I can't reproduce this with neither of those methods... It works as expected for me.
This is proving tricky to debug :) I've added: WITH_DEBUG_PORTS=x11/xscreensaver ... to /etc/make.conf, rebuilt xscreensaver, and I'm running it with lldb. However when the segfault happens it leaves the screen locked, preventing me from interacting further with lldb. I can unlock the system by switching to a different virtual console and killing lldb, but that obviously stops the debugging session. Anyways, this is what I've been able to glean so far: Process 35829 stopped * thread #1, name = 'xscreensaver-aut', stop reason = signal SIGSEGV: invalid address (fault address: 0x0) frame #0: 0x000000080066fe84 libc.so.7`strlen + 84 libc.so.7`strlen: -> 0x80066fe84 <+84>: movq (%rdi), %r11 0x80066fe87 <+87>: leaq (%r11,%r8), %rcx 0x80066fe8b <+91>: notq %r11 0x80066fe8e <+94>: andq %r11, %rcx ((lldb) Terminated (Terminated here is when I kill lldb from the virtual console).
Maybe what could be done is to attach lldb/gdb from the virtual console to an already running process before it crashes. Or start a whole thing in a misc/screen session and simply re-attach it in the virtual console. (I am sure that are better ways to tell the debuggers to use some other devices as the user interface though)
(In reply to Duncan Bayne from comment #3) Since the port is built with debug mode, why not just run it normally and generate the core? Then open it with gdb and do: thread apply all bt (or the equivalent thing in lldb)
Okay, it seems to be going bang inside the PAM auth code. Having rebuilt with -faddress=sanitize in both CFLAGS and LDFLAGS: xscreensaver-auth: 09:46:59: pwnam: couldn't get password of "duncan" xscreensaver-auth: 09:46:59: running as user "duncan" xscreensaver-auth: 09:46:59: PAM: pam_start ("xscreensaver", "duncan", ...) ==> 0 (Success) xscreensaver-auth: 09:46:59: pam_set_item (p, PAM_TTY, ":0.0") ==> 0 (Success) xscreensaver-auth: 09:46:59: pam_authenticate (...) ... xscreensaver-auth: 09:46:59: pam_conversation (ECHO_OFF="Password:") ... xscreensaver-auth: 09:46:59: mouse is at 1669,594 on monitor 0 1920x1080+0+0 "eDP-1" xscreensaver-auth: 09:46:59: theme: default xscreensaver-auth: 09:47:00: kbd layout: English (US) xscreensaver-auth: 09:47:00: re-creating window: size changed xscreensaver-auth: 09:47:02: X11 KeyPress xscreensaver-auth: 09:47:02: X11 KeyPress ... redacted ... xscreensaver-auth: 09:47:04: X11 KeyPress xscreensaver-auth: 09:47:04: authentication input finished xscreensaver-auth: 09:47:04: pam_conversation (...) ==> PAM_SUCCESS xscreensaver-auth: 09:47:04: pam_authenticate (...) ==> 0 (Success) xscreensaver-auth: 09:47:04: pam_acct_mgmt (...) ==> 0 (Success) AddressSanitizer:DEADLYSIGNAL ================================================================= ==11906==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x0008007e9e84 bp 0x7fffffffdf30 sp 0x7fffffffd6e8 T0) ==11906==The signal is caused by a READ memory access. ==11906==Hint: address points to the zero page. #0 0x8007e9e84 in strlen (/lib/libc.so.7+0x157e84) #1 0x8018f60c0 (/usr/lib/pam_exec.so.6+0x20c0) #2 0x8018f674f (/usr/lib/pam_exec.so.6+0x274f) #3 0x8005c3a21 in openpam_dispatch (/usr/lib/libpam.so.6+0x7a21) #4 0x8005c7e4b in pam_setcred (/usr/lib/libpam.so.6+0xbe4b) #5 0x31a138 in pam_try_unlock /usr/ports/x11/xscreensaver/work/xscreensaver-6.04/driver/passwd-pam.c:251:17 #6 0x3165eb in xscreensaver_auth /usr/ports/x11/xscreensaver/work/xscreensaver-6.04/driver/passwd.c:245:14 #7 0x2f78bf in main /usr/ports/x11/xscreensaver/work/xscreensaver-6.04/driver/xscreensaver-auth.c:325:12 #8 0x273dcf in _start /usr/src/lib/csu/amd64/crt1_c.c:75:7 #9 0x800357007 (<unknown module>) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/lib/libc.so.7+0x157e84) in strlen ==11906==ABORTING
(In reply to Duncan Bayne from comment #6) There is only one strlen() call in pam_exec.c: rc = pam_get_authtok(pamh, PAM_AUTHTOK, &authtok, NULL); if (rc == PAM_SUCCESS) { /* We include the trailing NUL-terminator. */ authtok_size = strlen(authtok) + 1; Since strlen(3) segfaults if the argument is null, I guess pam_get_authtok is somehow returning NULL for authtok. des@ (pam maintainer in copy).
1. Which FreeBSD version? 2. Do you have the source tree installed? 3. Do you have debugging symbols installed?
On that note, please read the UPDATING notice when 6.04 was committed: 2022-08-31 Affects: users of x11/xscreensaver on 13.1-RELEASE Author: zirias@ Reason: With the update to 6.04, xscreensaver now uses security/unix-selfauth-helper for PAM authentication. This relies on pam_exec.so, which had a bug causing a segfault on authentication attempts prior to 13.1-RELEASE-p1. For details, please see https://www.freebsd.org/security/advisories/FreeBSD-EN-22:19.pam_exec.asc Make sure your system is fully upgraded, otherwise you might be unable to unlock your screen. Even on other releases, you need to make sure that your system is updated to something past 13.1-RELEASE-p1's release date.
(In reply to Charlie Li from comment #9) That's probably it. Can the OP confirm which FreeBSD version is using?
Yes, this bug does still exist in 13.1-RELEASE-p5 releng/13.1-753d65a19 Tested against a from-scratch fresh build and fresh ports tree, running under Xorg. Happens as OP desdcribed, /usr/local/bin/xscreensaver-hacks/xscreensaver-auth seg-faults on a good password. Verified against both $1 and $6 hashed passwords. lldb run on the core says: (lldb) bt all * thread #1, name = 'xscreensaver-auth', stop reason = signal SIGSEGV * frame #0: 0x0000000500664e84 libc.so.7`strlen + 84 frame #1: 0x0000000500bfb0c1 Aside: we shouldn't closing active bugs for "Feedback Timeout" in just a month (didn't get a reply). Perhaps OP is busy during the month of western holidays, or otherwise unable to follow up, but the bug still exists and is egregious (core function of port is broken).
Reopening since apparently the bug still exists. Note: Yes, we should close bugs if no feedback is provided, especially if the bug is not reproducible for some of the developers that tried (aka, me) and a reasonable explanation was provided (bug prior 13.1 p1). If anything, PRs can be reopened as in this case, what causes no trouble at all.
It looks pretty suspicious that it's again a call to strlen() that bombs, so first thing I would verify is that the pam_exec.so is *indeed* the patched version. What architecture is this and how exactly did you install (or update) your base system? Then, of course, what are the contents of /usr/local/etc/pam.d/xscreensaver and, if it's included as expected, /etc/pam.d/system? A stacktrace with some actual info would certainly be helpful as well. FWIW, I just checked the source of xscreensaver-auth for direct calls to strlen(), there are only two of them and they both seem perfectly safe.
I've upgraded to xscreensaver 6.06 (11-Dec-2022), and the problem has been resolved. I can lock the screen and unlock it without xscreensaver-auth crashing :)
Ur, athough I've also applied a bunch of base patches too. So I'm afraid it could either be those *or* the xscreensaver changes. Looking at the diffs between 6.04 and 6.06 there's nothing obvious (to me ;) ) that would fix this.
Closing. Using "Overcome by events" due to the lack of a better category fit. Thanks!