Contents of screen sometimes revealed when screensaver is active
Qubes OS release
Qubes-4.2.202305221524-x86_64.iso
Brief summary
A recent Qubes OS 4.2 weekly sometimes reveals the contents of the screen behind the XScreenSaver dialog, even before the user has entered their password. This behavior was observed on a Lenovo T480.
Steps to reproduce
- Wait for screensaver to become active
- Press any key
Expected behavior
Only password dialog is visible
Actual behavior
Previous screen contents are visible behind password dialog
Similar report (but about external monitors): #4394
This should be fixed with https://github.com/QubesOS/updates-status/issues/3758. I'll close it for now, but please leave a comment if that still happens with that update installed.
I'm no longer seeing the issue on 4.2RC1 :)
I just had this happen on a 2 monitor desktop. Desktop contents fully visible behind lock screen after screen unblanking.
No additional guivm enabled.
amd-gpu-firmware 1:20250211-1
amd-ucode-firmware 1:20250211-1
lightdm 1.32.0-2
lightdm-gobject 1.32-0-2
lightdm-gtk 2.0.8-3
qubes-core-dom0 4.2.37-1
qubes-desktop-linux-common 4.2.12-1
qubes-gui-daemon 4.2.8-1
qubes-gui-dom0 4.2.8-1
qubes-release 4.2-12
xen-hypervisor 2001:4.17.5-6
xen-runtime 2001:4.17.5-6
xscreensaver-base 2:6.08-1.fc37
xscreensaver-gl-base 2:6.08-1.fc37
xfce4-sesssion 4.16.0-6
xfdesktop 4.16.1-1
xfwm4 1000:4.16.1-4
xorg-x11-drv-amdgpu 23.0.0-1
Nothing really stands out in journalctl or Xorg.0.log.
In .xsession-errors, I see the following (possibly unrelated) error occasionally:
disp-always-the-same: Sending monitor layout
asyncio: Task exception was never retrieved
future: <Task finished name='Task-15498' coro=<DAEMONLauncher.send_monitor_layout() done, defined at /usr/lib/python3.11/site-packages/qubesadmin/tools/qvm_start_daemon.py:384> exception=FileNotFoundError(2, 'No such file or directory')>
Traceback (most recent call last):
File "/usr/lib/python3.11/site-packages/qubesadmin/tools/qvm_start_daemon.py", line 407, in send_monitor_layout
with open(self.guid_pidfile(vm.xid), encoding='ascii') as pidfile:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory: '/var/run/qubes/guid-running.283'
Had this happened again a few times on updates systems.
Additionally, when the display has been blanked and the screen locked, waking it up by keyboard will often have the unlocked desktop flash very briefly on the screen before the unlock screen appears (can be verified by HDMI capture). This is not as obviously observable but still an obvious security issue. More rarely, as described in the issue, the desktop gets "stuck" under the unlock-box instead of black overlay as described in issue.
Observations: This occurs more frequently when using a particular (cheap, unpowered) HDMI switch or when connecting the machine directly to display, but very rarely on laptop if no external displays are connected and less commonly on a separate HDMI switch with external power. When using the HDMI switch I can almost always at least see the unlocked desktop briefly flash by on wake even when not resulting in the persistent-background effect.
So to summarize roughly:
- Laptop, no external displays: Rare if ever
- Laptop, external display by direct HDMI: Occasionally
- Workstation, direct HDMI: Occasionally
- Workstation, unpowered HDMI switch: Frequently
- Workstation, powered HDMI switch: Rarely
Makes me suspect some form of race conditions with display outputs getting connected/disconnected on display wake in locked state.
Sometimes I get the impression that the different sides of the HDMI link "talk past each other" with detecting/triggering display signal on/off with a couple of rounds of on/off before it settles (sometimes resulting in undesired "off" requiring a display or switch input or power cycle). That by itself may not be Qubes-specific but could be a contributing factor.
I am having this same problem on multiple devices, but today I finally got a video of it from my 4x monitor desktop. This is a workstation that I use multiple days a week, and has an uptime of about 50 days. Unfortunately, I do not have a plausible root cause yet.
This is about the third or fourth time I've seen this, and I think the second machine. I suspect this has only been in instances where I am using an external display(s), but I am not certain. However, this is the first time I caught it in the moment, and remembered to record a video: https://github.com/user-attachments/assets/27fb1543-f726-47aa-8a46-1381572befd5
I am on fully updated QubesOS 4.2.4, and in this case, I came back to my desk in the morning to find my workstation in this state, without any input from me or anyone else overnight