SUMMARY I didn't find this bug, but it's observed by a user in Arch Linux CN group. On resuming from hibernation there are brief moments where keyboard inputs are not **reliably** blocked by lock screen but instead sent to the window behind the lock screen. An attacker may abuse this small time-window to bypass the lock screen by using hardware keyboard macro "loginctl unlock-session [Enter]" if the last focused window is a terminal emulator. STEPS TO REPRODUCE 1. Enter hibernation mode (suspend-to-disk) using the power button in Application Launcher 2. Wake up from hibernation 3. Attempt to unlock KDE Plasma by typing the password OBSERVED RESULT (As described by the user who reported this bug) On typing, some keys are not getting captured by KScreenLocker and the first unlock attempt failed for providing wrong password. The user successfully unlocked the session on second attempt, the lock screen is dismissed, and the user found that some of the keyboard input events not captured on first attempt are shown on the focused text box. EXPECTED RESULT No keyboard input event should be allowed to pass-through lock screen ever. SOFTWARE/OS VERSIONS Linux/KDE Plasma: (available in About System) KDE Plasma Version: 6.0.2 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 ADDITIONAL INFORMATION It's Wayland session as the user reported.
CCing some people who might have an insight on this bug.
FWIW I can't reproduce on arch linux, wayland, git build. After resuming from suspend to ram, the lockscreen is fully functional and gets all key presses. Is there a downstream bug report for this? I didn't find it on the archlinux CN forums. Is the user using the default breeze theme?
(In reply to fanzhuyifan from comment #2) > Is the user using the default breeze theme? The user reports using the oxygen theme (so not a 3rd party theme).
Confirming if this is X11 or Wayland and whether systemd is used would be useful. Without systemd then it is inherently racey; the lid closes, we start locking, we haven't necessarily finished locking. It would also be interesting to know if a virtual keyboard / input method for typing chinese characters is in use.
I'm the user talked above. I'm using wayland session of kde. Systemd used. I found it's hard to reproduce it after I encountered this for the first time. I have tried for several times but nothing went wrong. I'm using fcitx5 with default chinese support, but I can't remember if it was activated when the issue occured. The application my password partially "passed" into was firefox. My CPU is Intel(R) Core(TM) i3-7100, and no extra gpu. The version of mesa is 24.0.2 but I'm not sure if it's relavant. If more info is needed pls let me know.
(In reply to fanzhuyifan from comment #3) > (In reply to fanzhuyifan from comment #2) > > Is the user using the default breeze theme? > > The user reports using the oxygen theme (so not a 3rd party theme). I misunderstood what's the "theme". After checking the settings I found that I'm using the default breeze theme, with "color", "application style", "window decoration", "cursor", "sound" and "welcome screen" changed to oxygen. I did this for I didn't notice that there's a "global theme" as the parent option of these subfields..
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!