[Bug]: sudo rejects correct password, PAM_BAD_JUMP in stock pambase auth config

### Kernel

7.1.5-1-cachyos

### Desktop Environment / Window Manager

KDE Plasma

### CPU

Intel Core i5-9300H @ 2.40GHz (8 threads)

### GPU / Driver

NVIDIA GeForce GTX 1650 Mobile / Max-Q (TU117M) + Intel UHD 630 (CoffeeLake-H) / nvidia 610.43.03

### Description

sudo (and su, and the current-password check in passwd) reject the correct password on the stock pambase auth chain. The password is NOT wrong, verified byte-for-byte against the /etc/shadow hash (`$y$/yescrypt`, unchanged since install) with crypt() against the host's libcrypt.so.2 (the library pam_unix.so actually loads). Logs never show a classic wrong-password "authentication failure"; every attempt logs instead:

> pam_unix(sudo:auth): conversation failed
> pam_unix(sudo:auth): auth could not identify password for [user]

"auth could not identify password" is the pam_unix message when pam_get_authtok() fails (pam_unix_auth.c), the token never reaches the hash comparison. Greeter login keeps working, (account is in nopasswdlogin), which makes it look like a password problem. It isn't.

Root cause found by bisecting the auth chain: the stock control flag [success=1 default=bad] on the pam_unix.so line makes libpam fail (PAM_BAD_JUMP, "bad jump in stack") when pam_unix returns success on this setup. Changing that one control to "required" (functionally equivalent for a single auth module) fixes auth completely.

### Steps to Reproduce

1. Stock config: /etc/pam.d/sudo = "auth include system-auth"; /etc/pam.d/system-auth auth section contains:

> -auth [success=2 default=ignore] pam_systemd_home.so
auth [success=1 default=bad] pam_unix.so try_first_pass nullok
auth optional pam_permit.so
auth required pam_env.so

2. printf '%s\n' '' | sudo -k -S true

> FAILS (rc 1, ~2 s delay: pam_unix's pam_fail_delay 2,000,000 µs). Journal shows the "conversation failed" + "could not identify password" pair.

3. Same command with a deliberately WRONG password, also fails, but journal then shows the classic "authentication failure", proving that in step 2 the correct password is never even compared.

4. Change ONLY the pam_unix.so auth line's control to "required" (everything else identical):

> auth required pam_unix.so try_first_pass nullok
same command SUCCEEDS (rc 0, ~60 ms). Wrong password still rejected.

5. Bisection matrix (3 runs each, same password, only the auth section varied):

> required pam_unix.so -> OK
[success=1 default=bad] pam_unix.so (only module) -> FAIL, "bad jump in stack"
[success=1 default=bad] pam_unix.so + permit + env -> FAIL (conv errors)
stock chain incl. pam_systemd_home (via include) -> FAIL
required pam_unix.so + permit + env -> OK

### Expected Behavior

The correct password authenticates against the stock pambase config (it matches the /etc/shadow hash per crypt()). Sudo/su/passwd should accept it, as they did on the same config until 2026-08-26.

### Actual Behavior

Authentication fails before the password comparison with PAM_BAD_JUMP (journal: "PAM bad jump in stack", from libpam pam_dispatch.c: an unsatisfiable success=N skip is treated as a config syntax error) / pam conversation errors. Affects sudo, su, and passwd. NOT fixed by reboot or re-login (deterministic on this machine, unlike most forum reports). faillock is NOT the cause: it is commented out in system-auth since pambase 20260616-1, and faillock shows no entries.

### Logs / Error Messages

https://paste.cachyos.org/p/b81cc02.log

### Additional Context

Packages: pam 1.7.2-2.1; pambase 20260616-1; sudo 1.9.17.p2-6.1; systemd 261.2-1; libxcrypt 4.5.2-1.1; glibc 2.44+r3+g0b05bc142249-1

- Same symptom+journal signature reported on the forum since ~Sep 2025, no root cause published yet:

https://discuss.cachyos.org/t/password-the-correct-one-doesnt-work-randomly-after-fresh-install-after-an-update-and-even-when-witthin-a-logged-in-session-in-terminal-and-frequently/15747 (open, 34 posts, last Aug 2026)
https://discuss.cachyos.org/t/sudo-password-stops-working-suddenly/24377
https://discuss.cachyos.org/t/sudo-password-failure-loop-despite-correct-credentials-and-working-root-login/30370
https://discuss.cachyos.org/t/cant-install-updates-password-is-always-incorrect-even-though-its-correct/26855

- This machine is the first deterministic case I know of: works on the SAME config until 2026-08-26 (tailscale/osu-lazer installs via sudo succeeded), zero package/config/password changes since, fails from the next boots, so the trigger looks like runtime/session state exposing a latent config defect.
- pam_systemd_home.so (from systemd 261.2-1) runs first in the chain and here fails D-Bus activation of org.freedesktop.home1 ("unknown unit", systemd-homed installed but disabled). Removing that line does NOT fix it, so it is not the sole trigger.
- Account is in nopasswdlogin, greeter login does not prove the password works against shadow.
- The stock [success=1 default=bad] control flag predates and postdates the June pambase change (diffed both pambase packages); the June update only commented out faillock.
- Question for maintainers: does this reproduce on vanilla Arch (pam 1.7.2-2), or is it specific to the CachyOS pam 1.7.2-2.1 rebuild / systemd 261.2 pam_systemd_home? If generic, this is a linux-pam substack-dispatch issue (pam_dispatch.c) worth escalating upstream.

Start by reproducing the auth matrix using /etc/pam.d/sudo and the system-auth auth section. Read pam_dispatch.c and pam_unix_auth.c alongside the journal errors, then compare behavior on vanilla Arch and the CachyOS rebuild. Done means the trigger and affected component are identified, with a confirmed fix or an upstream report for the PAM_BAD_JUMP failure.

Written by the indexing model from the issue text.