I've been able to consistently reproduce this by building pam-1.1.7 twice. After downgrading to pam-1.1.6-r2, everything works fine again. Since this makes it impossible to log in into the system without using some kind of recovery, I will take the freedom of masking it. I will start debugging the issue now and get back with more information in a few minutes.
(gdb) bt #0 0x00007f4cb3d8e4f7 in _set_ctrl (pamh=pamh@entry=0x75a900, flags=0, remember=remember@entry=0x0, rounds=rounds@entry=0x0, pass_min_len=pass_min_len@entry=0x0, argc=0, argv=0x75bfb0) at /usr/src/debug/sys-libs/pam-1.1.7/Linux-PAM-1.1.7/modules/pam_unix/support.c:183 #1 0x00007f4cb3d8c740 in pam_sm_acct_mgmt (pamh=0x75a900, flags=<optimized out>, argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/sys-libs/pam-1.1.7/Linux-PAM-1.1.7/modules/pam_unix/pam_unix_acct.c:200 #2 0x00007f4cb57eacab in _pam_dispatch_aux (pamh=pamh@entry=0x75a900, flags=flags@entry=0, h=0x75bfd0, resumed=<optimized out>, use_cached_chain=0) at /usr/src/debug/sys-libs/pam-1.1.7/Linux-PAM-1.1.7/libpam/pam_dispatch.c:110 #3 0x00007f4cb57eb0c9 in _pam_dispatch (pamh=0x75a900, flags=0, choice=choice@entry=3) at /usr/src/debug/sys-libs/pam-1.1.7/Linux-PAM-1.1.7/libpam/pam_dispatch.c:407 #4 0x00007f4cb57ea5d6 in pam_acct_mgmt (pamh=<optimized out>, flags=<optimized out>) at /usr/src/debug/sys-libs/pam-1.1.7/Linux-PAM-1.1.7/libpam/pam_account.c:20 #5 0x0000000000403974 in ?? () #6 0x0000000000402715 in ?? () #7 0x00007f4cb5260955 in __libc_start_main () from /lib64/libc.so.6 #8 0x000000000040325d in ?? () Looking at it, we have an explicit case where pam_unix_acct.c:200 calls: ctrl = _set_ctrl(pamh, flags, NULL, NULL, NULL, argc, argv); with: int _set_ctrl(pam_handle_t *pamh, int flags, int *remember, int *rounds, int *pass_min_len, int argc, const char **argv) which writes to '*rounds' unconditionally to whether it is provided or NULL: if (on(UNIX_SHA256_PASS, ctrl) || on(UNIX_SHA512_PASS, ctrl)) { val=search_key ("SHA_CRYPT_MAX_ROUNDS", LOGIN_DEFS); if (val) { *rounds = strtol(val, NULL, 10); free (val); } } I don't see any obvious conditionals that would make this any kind of special.
(In reply to Michał Górny from comment #1) > which writes to '*rounds' unconditionally to whether it is provided or NULL: > > if (on(UNIX_SHA256_PASS, ctrl) || on(UNIX_SHA512_PASS, ctrl)) { > val=search_key ("SHA_CRYPT_MAX_ROUNDS", LOGIN_DEFS); > > if (val) { > *rounds = strtol(val, NULL, 10); > free (val); > } > } Since all this works fine for me it seems to me that you explicitly set SHA_CRYPT_MAX_ROUNDS in login.defs (it's uncommented on my systems) and it only then pokes into an empty *rounds. Looks like a generic upstream bug. Since the check for the env is in _set_ctrl the best fix is probably to ensure that callers always provide a rounds parameter. Adding only a conditional check for (rounds != NULL) in _set_ctrl seems the wrong way to fix it but could help as additional safety measure/shortcut, implying that the caller doesn't care for explicitly configured rounds.
Thanks for masking it. Unfortunately it worked fine here when I tried logging in here, but indeed that's a big issue. Another issue is selinux failing to build :/
Please restore pam-1.1.6-r4.ebuild.
1.1.8 is out, so if that works maybe we can just close this bug and nuke 1.1.7.
pam-1.1.8 is in the tree now and unmasked. is this still an issue ?
No, it seems to have been fixed.
