Confirming as I can reproduce (also git master). 
I wonder if this is an issue with the source build or if this is reproducible on regular installs.

I am able to reproduce this bug on an install of Plasma6 on Solus, installed through a private repo where we're testing it

Confirmed on neon unstable.

Interesting, I cannot reproduce the issue. I do have fingerprint auth enabled, so maybe that changes the behavior somehow.

Confirmed, also seeing this with 6.0.1.

I can confirm that with 6.0.0 on Gentoo, but it happens only happens start from the 3rd sleep cycle. Logging in reset the failure count.

I also have this problem. The sleep also takes a while to do but that may just be a me problem. Also having memory problems with high usage that seem to build up over time, with all apps closed I'm idle on 3GB but have no idea if it's related. Spamming sleep also gets you locked out, had to wait 10 minutes for it to let me enter my password.

SOFTWARE/OS VERSIONS
Operating System: Manjaro Linux 
KDE Plasma Version: 6.0.4
KDE Frameworks Version: 6.1.0
Qt Version: 6.7.0
Kernel Version: 6.6.30-2-MANJARO (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 7730U with Radeon Graphics
Memory: 7.1 GiB of RAM
Graphics Processor: AMD Radeon Graphics
Manufacturer: Micro-Star International Co., Ltd.
Product Name: Modern 15 B7M
System Version: REV:1.0

*** Bug 488484 has been marked as a duplicate of this bug. ***

Never mind, I can reproduce it. The key for me is to go to sleep twice. Steps to reproduce for me:

1. Meta+L to lock
2. Click sleep button
3. Wake up machine (in my case, by briefly pressing the power button)
4. Click sleep again

It will now shake and then sleep, and then when waking up from sleep, shake again — in both cases displaying the failed login attempt text.

Confirming this issue with my setup. Has existed since Plasma 6 rolled out.

Operating System: EndeavourOS 
KDE Plasma Version: 6.2.0
KDE Frameworks Version: 6.7.0
Qt Version: 6.7.3
Kernel Version: 6.11.3-nitrous (64-bit)
Graphics Platform: Wayland

*** Bug 496152 has been marked as a duplicate of this bug. ***

Adding the phrase "Unlocking failed" for better search results.

Does it every time for me.

Comment 7's report that "Spamming sleep also gets you locked out" confirms what I suspected, but I can't confirm personally because I don't know how to configure that (something to do with PAM's faillock?).  So this is not merely cosmetic but fairly important.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Manjaro, linux 6.11.10-2-MANJARO x86_64
KDE Plasma Version: 6.2.4
KDE Frameworks Version: 6.8.0 
Qt Version: 6.8.1

*** Bug 499118 has been marked as a duplicate of this bug. ***

*** Bug 500451 has been marked as a duplicate of this bug. ***

Clicking on sleep in lockscreen also turns on fingerprint reader (500451), and in my case, turns on facial recognition (howdy)

It happens to me on ArchLinux with Wayland. I did it twice and journalctl showed:

Feb 16 23:13:42 kscreenlocker_greet[88142]: pam_unix(kde:auth): unexpected response from failed conversation function
Feb 16 23:13:42 kscreenlocker_greet[88142]: pam_unix(kde:auth): conversation failed
Feb 16 23:13:42 kscreenlocker_greet[88142]: pam_unix(kde:auth): auth could not identify password for []
Feb 16 23:13:51 kscreenlocker_greet[88142]: pam_unix(kde:auth): unexpected response from failed conversation function
Feb 16 23:13:51 kscreenlocker_greet[88142]: pam_unix(kde:auth): conversation failed
Feb 16 23:13:51 kscreenlocker_greet[88142]: pam_unix(kde:auth): auth could not identify password for []
Feb 16 23:13:58 kscreenlocker_greet[88142]: qt.qpa.wayland: Could not create EGL surface (EGL error 0x3000)
Feb 16 23:13:58 kscreenlocker_greet[88142]: Failed to write to the pipe: Bad file descriptor.

Recently stumbled upon this issue too. 

OS: Arch Linux 
KDE Plasma Version: 6.3.0
KDE Frameworks Version: 6.10.0
Qt Version: 6.8.2
Kernel Version: 6.12.13-1-lts (64-bit)
Graphics Platform: Wayland

I also experienced this today by accident.
I tried a bit too often to get my PC to sleep, and was then locked out like when I really enter my password multiple times (I think the limit was 3?) incorrectly.

FYI, you don't have to wait 10 minutes:
At least, if you don't have any open files or something else that could get corrupted with a hard reset, you can just power off the PC and the timeout is gone.

*** Bug 504961 has been marked as a duplicate of this bug. ***

>At least, if you don't have any open files or something else that could get corrupted with a hard reset, you can just power off the PC and the timeout is gone.

You can also run 

`sudo faillock --user david --reset` from a TTY.

If anyone can reliably reproduce, I need some more output. 

Please can you run the following:

❯ QT_LOGGING_RULES=kscreenlocker_greet.debug=true /opt/kde6/lib/libexec/kscreenlocker_greet --testing
and  reproduce the issue.

Also can you share /etc/pam.d/kde  (they differ per distro)

and output of `faillock --user $USER`

I can reproduce it. Here's the requested information:



$ QT_LOGGING_RULES='kscreenlocker_greet.debug=true' ~/kde/usr/lib64/libexec/kscreenlocker_greet --testing
kscreenlocker_greet: Greeter is starting up.
kscreenlocker_greet: [PAM worker kde-smartcard] start: successfully started
kscreenlocker_greet: [PAM worker kde-fingerprint] start: successfully started
kscreenlocker_greet: [PAM worker kde] start: successfully started
kscreenlocker_greet: Greeter is running in testing mode
kscreenlocker_greet: Testing mode enabled: true
Locked at 1749055944
qml: The backend got an unknown wallpaper provider type. The wallpaper will now fall back to the default. Please check your wallpaper configuration!
kscreenlocker_greet: PamAuthenticators: starting authenticators
kscreenlocker_greet: PamAuthenticators: state changing from PamAuthenticators::Idle to PamAuthenticators::Authenticating
kscreenlocker_greet: [PAM worker kde-fingerprint] Authenticate: Starting authentication
kscreenlocker_greet: [PAM worker kde] Authenticate: Starting authentication
kscreenlocker_greet: [PAM worker kde-smartcard] Authenticate: Starting authentication
kscreenlocker_greet: [PAM worker kde-smartcard] Message: Info message: auth=authinfo_unavail
kscreenlocker_greet: [PAM worker kde-smartcard] Authenticate: Authentication done, result code: 9 (Authentication service cannot retrieve authentication info)
file:///home/nate/kde/usr/share/plasma/shells/org.kde.plasma.desktop/contents/lockscreen/LockOsd.qml:10:1: "../osd": no such directory
kscreenlocker_greet: PamAuthenticators: Availability changed for non-interactive authenticator kde-fingerprint true
kscreenlocker_greet: PamAuthenticators: Availability changed for non-interactive authenticator kde-smartcard true
kscreenlocker_greet: PamAuthenticators: Info message from non-interactive authenticator kde-smartcard
kscreenlocker_greet: PamAuthenticators: Delay started on login failure for non-interactive authenticator kde-smartcard duration: 0
kscreenlocker_greet: PamAuthenticators: Availability changed for non-interactive authenticator kde-smartcard false
kscreenlocker_greet: PamAuthenticators: Availability changed for non-interactive authenticator kde-smartcard false
kscreenlocker_greet: [PAM worker kde] Message: Echo-off prompt: Password: 
kscreenlocker_greet: [PAM worker kde] Starting nested event loop to await response
kscreenlocker_greet: PamAuthenticators: Secret prompt from interactive authenticator kde
kscreenlocker_greet: [PAM worker kde-fingerprint] Authenticate: Authentication done, result code: 9 (Authentication service cannot retrieve authentication info)
kscreenlocker_greet: PamAuthenticators: Delay started on login failure for non-interactive authenticator kde-fingerprint duration: 0
kscreenlocker_greet: PamAuthenticators: Availability changed for non-interactive authenticator kde-fingerprint false
kscreenlocker_greet: PamAuthenticators: Availability changed for non-interactive authenticator kde-fingerprint false
kscreenlocker_greet: PamAuthenticators: cancelling interactive authenticator
kscreenlocker_greet: [PAM worker kde] Received cancellation, exiting with PAM_CONV_ERR
kscreenlocker_greet: [PAM worker kde] Nested event loop's exit code was not zero, bailing
kscreenlocker_greet: [PAM worker kde] Message: Echo-off prompt: Password: 
kscreenlocker_greet: [PAM worker kde] Starting nested event loop to await response
kscreenlocker_greet: PamAuthenticators: Secret prompt from interactive authenticator kde
kscreenlocker_greet: PamAuthenticators: responding to interactive authenticator
kscreenlocker_greet: [PAM worker kde] Received response, exiting nested event loop
kscreenlocker_greet: PamAuthenticators: Interactive authenticator kde changed business
kscreenlocker_greet: PamAuthenticators: Delay started on login failure for interactive authenticator kde duration: 1748302
kscreenlocker_greet: [PAM worker kde] Authenticate: Authentication done, result code: 7 (Authentication failure)
kscreenlocker_greet: PamAuthenticators: Interactive authenticator kde changed business
kscreenlocker_greet: PamAuthenticators: Failure from interactive authenticator kde



$ cat /etc/pam.d/kde
auth        substack      password-auth
auth        include       postlogin

account     required      pam_nologin.so
account     include       password-auth

password    include       password-auth

session     required      pam_selinux.so close
session     required      pam_loginuid.so
session     required      pam_selinux.so open
session     optional      pam_keyinit.so force revoke
session     required      pam_namespace.so
session     include       password-auth
session     include       postlogin



$ sudo faillock --user $USER
[sudo] password for nate: 
nate:
When                Type  Source                                           Valid

*** Bug 513476 has been marked as a duplicate of this bug. ***

I am also experiencing this bug, on both Wayland and X11, with both the "Sleep" button and the "Hibernate" button on the lock screen.

SOFTWARE/OS VERSIONS
Operating System: Arch Linux
KDE Plasma Version: 6.6.1
KDE Frameworks Version: 6.23.0
Qt Version: 6.10.2
Kernel Version: 6.18.13-arch1-1 (64-bit)
Graphics Platform: X11 and Wayland

I believe I am encountering this issue.

Here's my system details:
Operating System: CachyOS Linux 
KDE Plasma Version: 6.7.2
KDE Frameworks Version: 6.27.0
Qt Version: 6.11.1
Kernel Version: 7.1.3-2-cachyos (64-bit)
Graphics Platform: Wayland
Processors: 24 × AMD Ryzen AI 9 HX 370 w/ Radeon 890M
Memory: 32 GiB of RAM (30.6 GiB usable)
Graphics Processor: AMD Radeon 890M Graphics
Manufacturer: Framework
Product Name: Laptop 13 (AMD Ryzen AI 300 Series)
System Version: A9

I do have the fingerprint reader set up and use it regularly to unlock (mentioning just in case it matters).

There is no "kde" under /etc/pam.d/ on my system.

I am able to reproduce the issue consistently using the steps below. I did these steps after running the kscreenlocker_greet testing command from David Edmundson's earlier comment.
1. Clicked on Sleep
2. Pressed power button to wake
3. Clicked on Sleep
4. Pressed power button to wake
    - "Unlocking failed" was briefly displayed, then the whole prompt disappeared and the background un-blurred
5. Wiggled mouse to bring back the prompt
    - The prompt was displayed with the warning message "The account is locked due to 3 failed logins. (10 minutes left to unlock)"
6. Entered password
    - Password was rejected; the warning message persisted
7. Switched to another tty, ran `faillock --user breser --reset` as root, and switched back
8. Entered password
    - The warning message did the rejection shake, then disappeared, leaving behind a clean prompt
9. Entered password
    - The warning message came back and persisted
10. Entered password
    - The warning message did the rejection shake, then disappeared, leaving behind a clean prompt
11. Entered password
    - Computer unlocked

Here's the whole terminal output:

```
~  
❯ export QT_LOGGING_RULES='kscreenlocker_greet.debug=true'  
  
~  
❯ /usr/lib/kscreenlocker_greet --testing  
kscreenlocker_greet: Greeter is starting up.  
kscreenlocker_greet: [PAM worker kde] start: successfully started  
kscreenlocker_greet: [PAM worker kde-fingerprint] start: successfully started  
kscreenlocker_greet: [PAM worker kde-smartcard] start: successfully started  
kscreenlocker_greet: Greeter is running in testing mode  
kscreenlocker_greet: Testing mode enabled: true  
Locked at 1783999728  
kscreenlocker_greet: PamAuthenticators: starting authenticators  
kscreenlocker_greet: PamAuthenticators: state changing from PamAuthenticators::Idle to PamAuthenticators::Authenticating  
kscreenlocker_greet: [PAM worker kde] Authenticate: Starting authentication  
kscreenlocker_greet: [PAM worker kde-fingerprint] Authenticate: Starting authentication  
kscreenlocker_greet: [PAM worker kde-smartcard] Authenticate: Starting authentication  
kscreenlocker_greet: PamAuthenticators: Availability changed for non-interactive authenticator kde-fingerprint true  
kscreenlocker_greet: PamAuthenticators: Availability changed for non-interactive authenticator kde-smartcard true  
kscreenlocker_greet: [PAM worker kde-smartcard] Authenticate: Authentication done, result code: 28 (Module is unknown)  
kscreenlocker_greet: PamAuthenticators: Delay started on login failure for non-interactive authenticator kde-smartcard duration: 2333552  
kscreenlocker_greet: PamAuthenticators: Availability changed for non-interactive authenticator kde-smartcard false  
kscreenlocker_greet: PamAuthenticators: Availability changed for non-interactive authenticator kde-smartcard false  
kscreenlocker_greet: [PAM worker kde] Message: Echo-off prompt: Password:    
kscreenlocker_greet: [PAM worker kde] Starting nested event loop to await response  
kscreenlocker_greet: PamAuthenticators: Secret prompt from interactive authenticator kde  
kscreenlocker_greet: [PAM worker kde-fingerprint] Message: Info message: Place your finger on the fingerprint reader  
kscreenlocker_greet: PamAuthenticators: Info message from non-interactive authenticator kde-fingerprint  
kscreenlocker_greet: PamAuthenticators: cancelling interactive authenticator  
kscreenlocker_greet: [PAM worker kde] Received cancellation, exiting with PAM_CONV_ERR  
kscreenlocker_greet: [PAM worker kde] Nested event loop's exit code was not zero, bailing  
kscreenlocker_greet: [PAM worker kde] Authenticate: Authentication done, result code: 20 (Authentication token manipulation error)  
kscreenlocker_greet: PamAuthenticators: Delay started on login failure for interactive authenticator kde duration: 1806636  
kscreenlocker_greet: PamAuthenticators: Failure from interactive authenticator kde  
kscreenlocker_greet: PamAuthenticators: state changing from PamAuthenticators::Authenticating to PamAuthenticators::Idle  
kscreenlocker_greet: [PAM worker kde-fingerprint] Authenticate: Authentication done, result code: 9 (Authentication service cannot retrieve authentication info)  
kscreenlocker_greet: PamAuthenticators: Delay started on login failure for non-interactive authenticator kde-fingerprint duration: 2063284  
kscreenlocker_greet: PamAuthenticators: Availability changed for non-interactive authenticator kde-fingerprint false  
kscreenlocker_greet: PamAuthenticators: Availability changed for non-interactive authenticator kde-fingerprint false  
kscreenlocker_greet: PamAuthenticators: starting authenticators  
kscreenlocker_greet: PamAuthenticators: state changing from PamAuthenticators::Idle to PamAuthenticators::Authenticating  
kscreenlocker_greet: [PAM worker kde] Authentication attempt too soon. This shouldn't happen!  
kscreenlocker_greet: PamAuthenticators: Failure from interactive authenticator kde  
kscreenlocker_greet: PamAuthenticators: state changing from PamAuthenticators::Authenticating to PamAuthenticators::Idle  
kscreenlocker_greet: PamAuthenticators: cancelling interactive authenticator  
kscreenlocker_greet: PamAuthenticators: starting authenticators  
kscreenlocker_greet: PamAuthenticators: state changing from PamAuthenticators::Idle to PamAuthenticators::Authenticating  
kscreenlocker_greet: [PAM worker kde] Authenticate: Starting authentication  
kscreenlocker_greet: [PAM worker kde] Message: Echo-off prompt: Password:    
kscreenlocker_greet: [PAM worker kde] Starting nested event loop to await response  
kscreenlocker_greet: PamAuthenticators: Secret prompt from interactive authenticator kde  
kscreenlocker_greet: PamAuthenticators: cancelling interactive authenticator  
kscreenlocker_greet: [PAM worker kde] Received cancellation, exiting with PAM_CONV_ERR  
kscreenlocker_greet: [PAM worker kde] Nested event loop's exit code was not zero, bailing  
kscreenlocker_greet: [PAM worker kde] Authenticate: Authentication done, result code: 20 (Authentication token manipulation error)  
kscreenlocker_greet: PamAuthenticators: Delay started on login failure for interactive authenticator kde duration: 1677028  
kscreenlocker_greet: PamAuthenticators: Failure from interactive authenticator kde  
kscreenlocker_greet: PamAuthenticators: state changing from PamAuthenticators::Authenticating to PamAuthenticators::Idle  
kscreenlocker_greet: PamAuthenticators: cancelling interactive authenticator  
kscreenlocker_greet: PamAuthenticators: starting authenticators  
kscreenlocker_greet: PamAuthenticators: state changing from PamAuthenticators::Idle to PamAuthenticators::Authenticating  
kscreenlocker_greet: [PAM worker kde] Authenticate: Starting authentication  
kscreenlocker_greet: [PAM worker kde] Message: Info message: The account is locked due to 3 failed logins.  
kscreenlocker_greet: [PAM worker kde] Message: Info message: (10 minutes left to unlock)  
kscreenlocker_greet: PamAuthenticators: Info message from interactive authenticator kde  
kscreenlocker_greet: PamAuthenticators: Info message from interactive authenticator kde  
kscreenlocker_greet: [PAM worker kde] Message: Echo-off prompt: Password:    
kscreenlocker_greet: [PAM worker kde] Starting nested event loop to await response  
kscreenlocker_greet: PamAuthenticators: Secret prompt from interactive authenticator kde  
kscreenlocker_greet: PamAuthenticators: responding to interactive authenticator  
kscreenlocker_greet: [PAM worker kde] Received response, exiting nested event loop  
kscreenlocker_greet: PamAuthenticators: Interactive authenticator kde changed business  
kscreenlocker_greet: [PAM worker kde] Authenticate: Authentication done, result code: 7 (Authentication failure)  
kscreenlocker_greet: PamAuthenticators: Delay started on login failure for interactive authenticator kde duration: 1510871  
kscreenlocker_greet: PamAuthenticators: Failure from interactive authenticator kde  
kscreenlocker_greet: PamAuthenticators: state changing from PamAuthenticators::Authenticating to PamAuthenticators::Idle  
kscreenlocker_greet: PamAuthenticators: Interactive authenticator kde changed business  
kscreenlocker_greet: PamAuthenticators: starting authenticators  
kscreenlocker_greet: PamAuthenticators: state changing from PamAuthenticators::Idle to PamAuthenticators::Authenticating  
kscreenlocker_greet: [PAM worker kde] Authenticate: Starting authentication  
kscreenlocker_greet: [PAM worker kde] Message: Echo-off prompt: Password:    
kscreenlocker_greet: [PAM worker kde] Starting nested event loop to await response  
kscreenlocker_greet: PamAuthenticators: Secret prompt from interactive authenticator kde  
kscreenlocker_greet: PamAuthenticators: responding to interactive authenticator  
kscreenlocker_greet: [PAM worker kde] Received response, exiting nested event loop  
kscreenlocker_greet: PamAuthenticators: Interactive authenticator kde changed business  
kscreenlocker_greet: [PAM worker] Fail delay function was called, but authentication result was a success!  
kscreenlocker_greet: [PAM worker kde] Authenticate: Authentication done, result code: 0 (Success)  
kscreenlocker_greet: PamAuthenticators: Success from interactive authenticator kde  
Unlocked

~ 1m 38s
❯ faillock --user $USER
breser:
When                Type  Source                                           Valid

```

*** Bug 523332 has been marked as a duplicate of this bug. ***

*** Bug 490924 has been marked as a duplicate of this bug. ***

*** Bug 522806 has been marked as a duplicate of this bug. ***

My symptoms don't match this much at all, but the bug that did match them better was duped to here, so here's what I've got:

1. Select Sleep from Kicker/kickoff/whatever menu
2. Laptop sleeps
3. Wake laptop
4. Immediately: Earthquake, "Unlocking failed", short timeout
5. After timeout, log back in as normal

Every time. First or multiple sleeps after cold boot, doesn't matter. (Not tried sleeping from locked because I don't ever do that. Can do if it's deemed useful to check.) Started happening *only* after upgrade plasma-6.4.4 -> 6.7.2.

But if y'all are adamant this belongs here as well, fine by me.

Info:
Operating System: Gentoo Linux 
KDE Plasma Version: 6.7.2
KDE Frameworks Version: 6.27.0
Qt Version: 6.11.1
Kernel Version: 7.1.1-gentoo (64-bit)
Graphics Platform: Wayland
Processors: 4 × Intel® Core™ i7-7600U CPU @ 2.80GHz
Memory: 16 GiB of RAM (15.4 GiB usable)
Graphics Processor: Intel® HD Graphics 620
Init: OpenRC

Oh boy, I think you hit a *combination* of this bug and Bug 510992. To verify if it's the same bug, can you try running in a terminal:

echo 1 > /sys/power/pm_print_times
echo 1 > /sys/power/pm_debug_messages
(try sleeping your system)
journalctl --system -b0 (then press the End key on your keyboard and scroll around looking for interesting log messages)?

Sorry, if "wake laptop" means you manually woke it and not by itself, I probably interpreted your comment wrong.

(In reply to nyanpasu64 from comment #31)
> Sorry, if "wake laptop" means you manually woke it and not by itself, I
> probably interpreted your comment wrong.

That is indeed what I meant. Got 99 problems but an insomniac laptop ain't one (to date).

And I thought I can't my password the first time :-) Didn't know it's a bug. 

Operating System: Fedora Linux 44
KDE Plasma Version: 6.7.3
KDE Frameworks Version: 6.28.0
Qt Version: 6.11.1
Kernel Version: 7.1.6-201.fc44.x86_64 (64-bit)
Graphics Platform: Wayland

Looks like I'm hitting this in combination with 490924. I am putting my laptop to sleep by lid trigger (X1 Carbon Gen 10), every time it gets woken up I am welcomed by "wrong password" prompt, even though I haven't even touched keyboard yet (lid switch counts as key press technically).
Steps to reproduce, currently 100% reproducible:
1. Enter sleep by closing the lid
2. Wait for it to enter sleep (LED on lid starts "breathing")
3. Wake it up by opening the lid
4. Enjoy "wrong password" without typing anything

I'm on arch and by default my systemd configures pam to lock me out on 3 failed attempts, so it's technically possible to get locked out of my account by simply closing and opening the lid a couple times in a row. Not using fingerprint unlock by the way.

Tested patched kscreenlocker 6.7.4 with MR 340 and it fixes the issue for me. Any reason it got held up?
https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/340

Operating System: Arch Linux 
KDE Plasma Version: 6.7.4
KDE Frameworks Version: 6.28.0
Qt Version: 6.11.1
Kernel Version: 6.18.39-273-tkg-bore (64-bit)
Graphics Platform: Wayland
Processors: 16 × 12th Gen Intel® Core™ i7-1270P
Memory: 32 GiB of RAM (31.0 GiB usable)
Graphics Processor: Intel® Iris® Xe Graphics
System Version: ThinkPad X1 Carbon Gen 10

Same here,

### System

* Fedora 44 KDE

* Wayland

* Issue started after upgrading to Fedora 44

### Problem

After the laptop has been **locked for some time** (especially after suspend), the **first password attempt on the KDE lock screen always fails**, even though I'm certain the password is correct.

The second attempt succeeds with the exact same password.

### Things I've noticed

* The problem **only happens on the KDE lock screen**.

* It **does not happen on the SDDM login screen** after a reboot.

* If I lock and immediately unlock the screen, authentication works on the first try.

* The issue appears only after the screen has been locked for a while or after waking from suspend.

* The most interesting observation is that if I **type my password, click the "show password" (eye) button, verify it is correct, and then press Enter**, it authenticates successfully on the first attempt every time.

### Logs

The journal shows the first authentication being rejected by PAM:

```
kscreenlocker_greet: pam_unix(kde:auth): authentication failure
unix_chkpwd: password check failed for user

```

A few seconds later, entering the same password succeeds.

The suspend/resume sequence itself appears clean, with no kernel, GPU, or SDDM errors.

### What I've tried

* Verified the password is correct.

* Reproduced the issue multiple times.

* Confirmed it only affects the lock screen.

* Collected `journalctl` logs around the failed authentication.

Created attachment 195053 [details]
journalctl log of a sleep-wake failed login

The source code lives at https://invent.kde.org/plasma/kscreenlocker/-/tree/v6.7.4?ref_type=tags.
We can enable logging via:
nano ~/.config/QtProject/qtlogging.ini
[Rules]
kscreenlocker_greet=true

How does kscreenlocker set up authentication?

// auth.cpp
class PamAuthenticator : public QObject {
    QThread m_thread;
    PamWorker *d;
PamAuthenticator::PamAuthenticator(const QString &service, const QString &user, NoninteractiveAuthenticatorTypes types, QObject *parent)
{
    d->moveToThread(&m_thread);

↑ This shows that PamWorker methods are invoked in a background thread, and run concurrently with UI operations.

(worker) PamWorker::PamWorker()
    : m_conv({&PamWorker::converse, this})

(main)void PamAuthenticator::init(const QString &service, const QString &user)
{
    QMetaObject::invokeMethod(d, [this, service, user]() {
        d->start(service, user);
    });
(worker) void PamWorker::start(const QString &service, const QString &user)
{
    m_service = service;
    if (user.isEmpty())
        m_result = pam_start(qPrintable(service), nullptr, &m_conv, &m_handle);
    else
        m_result = pam_start(qPrintable(service), qPrintable(user), &m_conv, &m_handle);
Aug 10 14:56:55 servlet kscreenlocker_greet[3848637]: [PAM worker kde-fingerprint] start: successfully started
Aug 10 14:56:55 servlet kscreenlocker_greet[3848637]: [PAM worker kde-smartcard] start: successfully started
Aug 10 14:56:55 servlet kscreenlocker_greet[3848637]: [PAM worker kde] start: successfully started

↑ Each potential unlock thread calls pam_start(), passing in m_conv -> PamWorker::converse().

(main) void PamAuthenticator::tryUnlock()
{
    m_unlocked = false;
    QMetaObject::invokeMethod(d, &PamWorker::authenticate);
(worker) void PamWorker::authenticate()
{
    qCDebug(KSCREENLOCKER_GREET, "[PAM worker %s] Authenticate: Starting authentication", qUtf8Printable(m_service));
Aug 10 14:56:56 servlet kscreenlocker_greet[3848637]: [PAM worker kde-fingerprint] Authenticate: Starting authentication
Aug 10 14:56:56 servlet kscreenlocker_greet[3848637]: [PAM worker kde] Authenticate: Starting authentication
Aug 10 14:56:56 servlet kscreenlocker_greet[3848637]: [PAM worker kde-smartcard] Authenticate: Starting authentication

↓ pam_authenticate() is a blocking call, that calls back into m_conv -> PamWorker::converse(). Each call-back receives a fixed number of commands, not an updatable stream.

    int rc = pam_authenticate(m_handle, 0); // PAM_SILENT);
    qCDebug(KSCREENLOCKER_GREET,
            "[PAM worker %s] Authenticate: Authentication done, result code: %d (%s)",
            qUtf8Printable(m_service), rc, pam_strerror(m_handle, rc));
Aug 10 14:56:56 servlet kscreenlocker_greet[3848637]: [PAM worker kde-smartcard] Authenticate: Authentication done, result code: 28 (Module is unknown)
Aug 10 14:56:56 servlet kscreenlocker_greet[3848637]: [PAM worker kde-fingerprint] Authenticate: Authentication done, result code: 28 (Module is unknown)

↑ At this point only the "kde" authenticator (password prompt) is active. pam_authenticate() calls into PamWorker::converse(): ↓
(worker) int PamWorker::converse(int n, const struct pam_message **msg, struct pam_response **resp, void *data)
{
    PamWorker *c = static_cast<PamWorker *>(data);

    *resp = (calloc pam_response[n])
    auto responses = std::span<pam_response>{*resp, nSize};
    auto messages = std::span<const pam_message*>{msg, nSize};
    for (const auto &[pamMessage, pamResponse] : std::views::zip(messages, responses)) {
        bool isSecret = false;
        switch (pamMessage->msg_style) {

There are two types of PAM prompts for user input. KDE's handling for them is... awkward.

            qCDebug(KSCREENLOCKER_GREET,
                    "[PAM worker %s] Message: %s: %s",
                    qUtf8Printable(c->m_service),
                    (isSecret ? "Echo-off prompt" : "Echo-on prompt"),
                    qUtf8Printable(prompt));
Aug 10 14:56:56 servlet kscreenlocker_greet[3848637]: [PAM worker kde] Message: Echo-off prompt: Password: 

            QEventLoop e;
            QObject::connect(c, &PamWorker::cancelled, &e, ...);
            qCDebug(KSCREENLOCKER_GREET, "[PAM worker %s] Starting nested event loop to await response", qUtf8Printable(c->m_service));
Aug 10 14:56:56 servlet kscreenlocker_greet[3848637]: [PAM worker kde] Starting nested event loop to await response
            // We are in a non-gui thread. It should be mostly fine to exec() here.
            int rc = e.exec();

↑ This is the point we reach with the lock screen open. There is a wedged call to pam_authenticate() -> PamWorker::converse(), that persists until we enter a password or sleep the system. In the latter case... ↓
Aug 10 14:56:58 servlet systemd-logind[734]: suspend requested from client PID 3848637 ('kscreenlocker_g') (unit user@1000.service)...
Aug 10 14:56:58 servlet systemd-logind[734]: The system will suspend now!

(main) void PamAuthenticators::cancel()
{
    qCDebug(KSCREENLOCKER_GREET) << "PamAuthenticators: cancelling interactive authenticator";
Aug 10 14:56:58 servlet kscreenlocker_greet[3848637]: PamAuthenticators: cancelling interactive authenticator
    d->interactive->cancel();
[void PamAuthenticator::cancel()]
{
    ... QMetaObject::invokeMethod(d, &PamWorker::cancelled);
}
e.exec() calls into [QObject::connect(&PamWorker::cancelled)] → [&]() {
                qCDebug(KSCREENLOCKER_GREET, "[PAM worker %s] Received cancellation, exiting with PAM_CONV_ERR", qUtf8Printable(c->m_service));
Aug 10 14:56:58 servlet kscreenlocker_greet[3848637]: [PAM worker kde] Received cancellation, exiting with PAM_CONV_ERR
                e.exit(PAM_CONV_ERR);
            }

            return from [int rc = e.exec()] = PAM_CONV_ERR
            if (rc != 0) {
                qCDebug(KSCREENLOCKER_GREET, "[PAM worker %s] Nested event loop's exit code was not zero, bailing", qUtf8Printable(c->m_service));
Aug 10 14:56:58 servlet kscreenlocker_greet[3848637]: [PAM worker kde] Nested event loop's exit code was not zero, bailing
                return rc;
            }

↑ Our pam_conv callback returns PAM_CONV_ERR. It seems that pam_authenticate() → pam_unix.so did not appreciate us returning PAM_CONV_ERR, and returns PAM_AUTHTOK_ERR=20 to the caller.
Aug 10 14:56:58 servlet kscreenlocker_greet[3848637]: [PAM worker kde] Authenticate: Authentication done, result code: 20 (Authentication token manipulation error)
Aug 10 14:56:58 servlet kscreenlocker_greet[3848637]: pam_unix(kde:auth): unexpected response from failed conversation function
Aug 10 14:56:58 servlet kscreenlocker_greet[3848637]: PamAuthenticators: Failure from interactive authenticator kde
Aug 10 14:56:58 servlet kscreenlocker_greet[3848637]: pam_unix(kde:auth): conversation failed

Worse yet, when pam_unix.so receives an erroneous reply from our callback, it doesn't just abort authentication, but libpam invokes pam_faillock.so in authfail mode, registering our suspend attempt as a failed login.

I've attached my full journal log of authentication errors.

----

Which authentication flow did we trigger in libpam?
void PamWorker::start(const QString &service, const QString &user)
{
        m_result = pam_start(qPrintable(service), qPrintable(user), &m_conv, &m_handle);
[int pam_start(const char *service_name, ...)];

Based on the log messages, we can infer service_name is "kde". /usr/lib/pam.d/kde redirects to system-local-login, /etc/pam.d/system-local-login redirects to system-login, and /etc/pam.d/system-login specifies four modes each with a sequential list of authenticator shared libraries. README.pam claims (consistent with my wild poking-around in linux-pam/libpam):

> PAM configuration files have four types of entries for each service,
> however KScreenLocker only uses the "auth" entries.  Other programs
> using PAM may use other entries.

The auth entries are:
auth       required   pam_shells.so
auth       requisite  pam_nologin.so
auth       include    system-auth

/etc/pam.d/system-auth contains:
auth       required                    pam_faillock.so      preauth
-auth      [success=2 default=ignore]  pam_systemd_home.so
auth       [success=1 default=bad]     pam_unix.so          try_first_pass nullok
auth       [default=die]               pam_faillock.so      authfail
...
auth       required                    pam_faillock.so      authsucc

So at this point we'd have to either configure pam_faillock (https://linux.die.net/man/8/pam_faillock, in the linux-pam repo) to ignore PAM_CONV_ERR as a failed unlock, or not *call* pam_authenticate() until the user has already entered a password. The first may be difficult, and we'd need to hide the stray "Unlocking failed" message another way (don't print an error upon PAM_AUTHTOK_ERR? if we've called PamWorker::cancelled()?). The second may break non-password unlock mechanisms the user installs into the kde → system-local-login → system-login → system-auth chain, since we only check for PAM authentication when the user enters a password and presses Enter (not if they plug in a security key, bring a smartphone, or anything else.).

See also https://github.com/ChocolateLoverRaj/pam-any/issues/19, I experienced something similar there over cancelling password prompts.

Created attachment 195054 [details]
/etc/pam.d/kde modified to not trigger faillock on sleep-wake

According to https://wpollock.com/AUnix2/PAM-Help.htm#advanced, we can recognize specific return codes (like AUTHTOK_ERR) and take specific actions, like "die" to avoid running subsequent faillock. I've prototyped an alternative /etc/pam.d/kde that appears to *work*! (no entries in faillock CLI after sleep and wake, and no "Unlocking failed" message):
auth       [success=1 authtok_err=die default=bad]     pam_unix.so          try_first_pass nullok

Note that authtok_err needs to be lowercase (unlike the above site), or else even the right password doesn't succeed.

I've attached my full modified kde file (made by inlining system-login and system-auth into the file, and editing the innermost system-auth commands). I'm not sure if these files could change in PAM updates or between distros/versions, and our KDE authentication chain would no longer work properly in that context.

Does anyone know if *not* triggering faillock upon the authtok_err return code could have any security implications? When I entered the wrong password on purpose, I still found an entry when running faillock in a terminal.

Tiny correction: the constructor `PamWorker::PamWorker()` runs on the main thread, and the PamWorker is moved to its own QThread afterwards. This has no bearing on my earlier debugging because PamWorker::PamWorker() only creates a QObject and data fields, no PAM session.

god i wish debugging frameworks printed the thread of a debug message

*** Bug 517564 has been marked as a duplicate of this bug. ***

(In reply to nyanpasu64 from comment #37)
> Created attachment 195054 [details]
> /etc/pam.d/kde modified to not trigger faillock on sleep-wake
> 
> According to https://wpollock.com/AUnix2/PAM-Help.htm#advanced, we can
> recognize specific return codes (like AUTHTOK_ERR) and take specific
> actions, like "die" to avoid running subsequent faillock. I've prototyped an
> alternative /etc/pam.d/kde that appears to *work*! (no entries in faillock
> CLI after sleep and wake, and no "Unlocking failed" message):
> auth       [success=1 authtok_err=die default=bad]     pam_unix.so         
> try_first_pass nullok
> 
> Note that authtok_err needs to be lowercase (unlike the above site), or else
> even the right password doesn't succeed.
> 
> I've attached my full modified kde file (made by inlining system-login and
> system-auth into the file, and editing the innermost system-auth commands).
> I'm not sure if these files could change in PAM updates or between
> distros/versions, and our KDE authentication chain would no longer work
> properly in that context.
> 
> Does anyone know if *not* triggering faillock upon the authtok_err return
> code could have any security implications? When I entered the wrong password
> on purpose, I still found an entry when running faillock in a terminal.

Definitely seems like a decent bandaid work around, but wouldn't consider this a long term fix. You're essentially just not logging the failure instead of actually preventing the failure from happening in the first place. From a security perspective, although the risk is likely small, you're losing brute force protection where someone/something malicious is leveraging an authentication token manipulation that results in an error. While this isn't the same as a straight up invalid password attempt, those malicious manipulation attempts would continue to happen silently, which is obviously not ideal.

My view is that "malicious manipulation attempts" are indistinguishable from sleeping KDE's lock screen, and would provide no system access or leaked bits (about the password being correct or not) to an attacker to the kde PAM service. Moreover it would not apply to regular system logins or sudo, because I separated the KDE service from the standard system ones it previously inherited from. Unless there's some way to guess a password and return PAM_AUTHTOK_ERR *if* it's incorrect?

Is it possible an attacker could use the kde service in a *non-kscreenlocker* process to brute-force your password without rate limiting? Maybe, but they could do the same thing with unix_chkpwd directly (which logs if incorrect).

Can you call pam_end() within a conversation? My gut instinct is no (it could cause state corruption and/or use-after-free), but I have not tested it...

In any case, if this is not an acceptable solution, I suppose the remaining option is to not initiate a pam_authenticate() transaction until the user submits a password. Rewriting kscreenlocker_greet to do this is above my pay grade...

I'm hitting this on a patched build, and specifically via the lid switch rather than the Sleep/Hibernate buttons — so MR 340 doesn't seem to cover this path.

Setup:

Arch Linux, kscreenlocker 6.7.4-1 (installed 2026-08-07, booted well after that, so the patched greeter is definitely running)
KDE Plasma 6.7.x, Wayland
Lenovo Yoga 9i 8th gen
No fingerprint reader configured; grep -r fprint /etc/pam.d/ is empty

Reproduction, 100% consistent:

Close the lid → machine suspends
Wait for it to fully enter sleep
Open the lid to wake
"Unlocking failed" shake appears before I've touched the keyboard

Journal on each lid-open:

kscreenlocker_greet[NNNN]: pam_unix(kde:auth): unexpected response from failed conversation function
kscreenlocker_greet[NNNN]: pam_unix(kde:auth): conversation failed
kscreenlocker_greet[NNNN]: pam_unix(kde:auth): auth could not identify password for [glitch]

one second after systemd-logind: Lid opened. With default Arch faillock (deny=3) this locks the account after a few lid cycles.

I confirmed it's the same early-conversation-cancelled mechanism described in comment 36: the authtok_err=die PAM tweak from comment 37 stops faillock counting it (no more lockout), but the spurious failure and shake on wake persist because the conversation is still started and cancelled on resume. So on the lid path the fix would need the same "don't start pam_authenticate() until a password is actually submitted" change, not just the button handling.

Happy to provide full debug output from kscreenlocker_greet --testing if useful.

Confirming on Gentoo with OpenRC and elogind (no systemd, no SSSD). Same signature as comment 37/38: the failure fires at the exact second of resume, before any input:

  Aug 29 18:37:43 fritz kernel: PM: suspend entry (deep)
  Aug 29 18:37:52 fritz kernel: PM: suspend exit
  Aug 29 18:37:52 fritz kscreenlocker_greet[19254]: pam_unix(kde:auth): unexpected response from failed conversation function
  Aug 29 18:37:52 fritz kscreenlocker_greet[19254]: pam_unix(kde:auth): conversation failed
  Aug 29 18:37:52 fritz kscreenlocker_greet[19254]: pam_unix(kde:auth): auth could not identify password for [shutty]

Eight identical occurrences over a week, so the 9e622c86 regression also reproduces with elogind's PrepareForSleep, not just systemd-logind. Plain lock/unlock without suspend never logs it.

A symptom variant worth recording for duplicate-hunting: depending on when you start typing after resume, instead of the shake you may just get no password dots while typing, with the unlock still succeeding.

That's the field being unresponsive during the fail delay from the phantom failure. The greeter also logs "[PAM worker kde] Authentication attempt too soon. This shouldn't happen!" when this happens. Reports of "invisible password characters after suspend" may be this bug.

With MR !340 (commit 992f3fa8) rebased onto the 6.7.4 tarball (the MR diff no longer applies there, but only the connect() removal is needed), a suspend/resume cycle logs no PAM failure, first password is  accepted, and the faillock tally stays empty. One clean cycle so far against eight failed pre-patch ones. Note for the fingerprint discussion on the MR: fprintd is still D-Bus-activated by the greeter on  resume post-patch, so pam_fprintd does start.

  Operating System: Gentoo (OpenRC, elogind 257.16)
  KDE Plasma Version: 6.7.4
  Qt Version: 6.11.2
  Graphics Platform: Wayland
  Hardware: ThinkPad, Synaptics Prometheus fingerprint reader (06cb:00bd), enrolled

(In reply to nyanpasu64 from comment #41)
> My view is that "malicious manipulation attempts" are indistinguishable from
> sleeping KDE's lock screen, and would provide no system access or leaked
> bits (about the password being correct or not) to an attacker to the kde PAM
> service. Moreover it would not apply to regular system logins or sudo,
> because I separated the KDE service from the standard system ones it
> previously inherited from. Unless there's some way to guess a password and
> return PAM_AUTHTOK_ERR *if* it's incorrect?
> 
> Is it possible an attacker could use the kde service in a
> *non-kscreenlocker* process to brute-force your password without rate
> limiting? Maybe, but they could do the same thing with unix_chkpwd directly
> (which logs if incorrect).
> 
> Can you call pam_end() within a conversation? My gut instinct is no (it
> could cause state corruption and/or use-after-free), but I have not tested
> it...
> 
> In any case, if this is not an acceptable solution, I suppose the remaining
> option is to not initiate a pam_authenticate() transaction until the user
> submits a password. Rewriting kscreenlocker_greet to do this is above my pay
> grade...

I think your points are all fair, which is why I stated the risk is likely small. I think the crux of my comment still stands though that this should only be considered a "bandaid". You're not solving the problem, you're alleviating a symptom of it by preventing an erroneous lockout of the account.

Confirm it happens also on Fedora 44 with Plasma 6.7.2. Suspending via the suspend button does immediately show the failed login attempt. Once i wake it up again it does trigger the wait timer which prevents me from immediately unlocking the device. The same exact issue happens when the device suspends by itself and every time i wake it up by keyboard, touchpad or lid, I have to wait a couple seconds to insert my password.

Operating System: Fedora Linux 44
KDE Plasma Version: 6.7.5
KDE Frameworks Version: 6.29.0
Qt Version: 6.11.2
Kernel Version: 7.2.4-200.fc44.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 18 × Intel® Core™ Ultra 5 125H
Memory: 16 GiB of RAM (15.3 GiB usable)
Graphics Processor: Intel® Arc
Manufacturer: Micro-Star International Co., Ltd.
Product Name: Modern 15 H AI C1MG
System Version: REV:1.0

This bug was originally posted February 2024.  I assume this has not been licked up for a few reasons.

1.  The description is far from accurate at this point.  It makes it sound like a mild annoyance when in fact it is a pretty nasty bug.
2.  Because of different PAM policies for different distros, there may be a thought to ignore this and hope it goes away, or blame the PAM policy.

My suggestions. 
1.  Someone needs to update the description to accurately reflect the nature of this bug.
2.  This is irrelevant because the bug is that uninitiated authentication should NEVER happen at all.  The greeter initiating PAM conversation on resume is a bug that exists everywhere.  The fact that some distros put the faillock threshold high, or don't have it at all, is irrelevant.

On a system with more than one user, where one or more of them don't have root access, this can lock them out until they can contact a user with root access or wait 10 minutes.  I understand this isn't a hyper critical bug, but sitting for more than 2 years?  There has to be another reason why it hasn't been picked up in that time other than triage.

*** Bug 521900 has been marked as a duplicate of this bug. ***

I was going to log a new issue for "plasma unlock screen shows "Failed login" after resuming from sleep" but after finding this bug and testing it I believe my issue is the back half of this issue. I have tested this issue and can confirm they both occur together.

The interesting part is this bug also occurs on my system without any user input. If I leave the system unattended it will firstly lock the screen after 5 minutes, then sleep after 15.  When I wake the system the unlock screen is already showing a "Failed login" prompt. This is without any user input whatsoever either before sleep or after it.

The bug does also occur with manual sleep from the lock screen as described elsewhere in this bug report.

Another user reported the issue here also: https://discuss.kde.org/t/failure-to-unlock-after-waking-from-extended-sleep-mode/50160?u=smash

(In reply to Ash from comment #48)
> I was going to log a new issue for "plasma unlock screen shows "Failed
> login" after resuming from sleep" but after finding this bug and testing it
> I believe my issue is the back half of this issue. I have tested this issue
> and can confirm they both occur together.
> 
> The interesting part is this bug also occurs on my system without any user
> input. If I leave the system unattended it will firstly lock the screen
> after 5 minutes, then sleep after 15.  When I wake the system the unlock
> screen is already showing a "Failed login" prompt. This is without any user
> input whatsoever either before sleep or after it.
> 
> The bug does also occur with manual sleep from the lock screen as described
> elsewhere in this bug report.
> 
> Another user reported the issue here also:
> https://discuss.kde.org/t/failure-to-unlock-after-waking-from-extended-sleep-
> mode/50160?u=smash

Yeah, it affects every method of entering suspension. Also here on my laptop.

There should be no password drama on Plasma 6.8 since we now outright abort the authentication flows.

(In reply to Harald Sitter from comment #50)
> There should be no password drama on Plasma 6.8 since we now outright abort
> the authentication flows.

Will it also fix Bug 523906 , where closing "policykit-kde-agent-1" windows is interpreted as entering the wrong password, putting the user in cooldown even though they didn't even interact with the input field?

No

I can reliably reproduce this issue on Nyarch Linux (Arch-based), KDE Plasma on Wayland.
Hardware: ASUS TX Gaming FX608JMR
Kernel: 7.2.6-arch2-1
Steps to reproduce:
1. Lock the session.
2. On the Plasma lock screen, click the Sleep button.
3. Wake the laptop again.
4. Repeat this a few times.
Observed result:
Clicking Sleep on the lock screen causes an authentication failure even though I did not enter or submit any password. After repeating this several times, the failed attempts accumulate in faillock and the account becomes temporarily locked.
This appears to be specific to the Sleep button on the Plasma lock screen.
The following suspend methods do not cause the problem on the same machine:
- systemctl suspend
- the laptop's hardware sleep key
- closing the lid
Manually locking the screen itself also works normally.
After suspending via the lock-screen Sleep button, waking with the built-in keyboard, mouse, or touchpad can make the lock screen react as if an input/authentication interaction occurred.
So in my case the suspend/resume mechanism itself works correctly; the problem appears to be specifically in the lock-screen Sleep action / authentication handling.
I can reproduce this consistently.
I am happy to provide journalctl, PAM configuration, or faillock output if needed.

I have the same / a similar issue, but in my case my laptop going to sleep automatically also causes a failed login attempt. This paired with a different issue waking up the laptop sporadically causes me to get locked out of my laptop if I just leave it sit open for a while.

This issue is marked as resolved / fixed, but there is no commit linked, and the fix version is not yet released. Is there a way for me to install the fixed version?

I think there's still something wrong here. I'll do another pass on the code hopefully next week.

I've seen this on Plasma 6.7.5 and git-master as well

*** Bug 526721 has been marked as a duplicate of this bug. ***