GNOME Bugzilla – Bug 736856
sensitive data may be seen after calling reboot
Last modified: 2021-07-05 14:04:48 UTC
When box is locked, anybody can call reboot, and while rebooting he can see user's open applications, and probably sensitive data may be compromised.
are you saying the reboot button is showing up at the lock screen?
User switch maybe?
There's an SNA bug where it will randomly show an old framebuffer. I've had screenshots of old apps appear while VT switching and rebooting.
*** Bug 737226 has been marked as a duplicate of this bug. ***
My bug report was linked to this one. Here is a video of my issue happening: https://www.dropbox.com/s/c6gmmwn90qyymms/VID_20140802_040320.mp4 I am running Radeon hardware for what it is worth, and I was not aware that SNA could affect Radeon hardware
(In reply to comment #5) > I was not aware that SNA could affect Radeon hardware Sounds like a different issue then. :/ By the way, don't post an mp4 video if you expect it to be viewed; please post a webm video instead. You can attach it directly to this bug tracker using the attachment feature. Normally I'd suggest taking the screencast with Ctrl+Alt+Shift+R in gnome-shell, but I guess that's unlikely to work for this bug....
The mp4 is hosted on dropbox which contains it's own player. I recorded it with my phone which does not have a webm record codec, and the file was too big to be attached in the bug itself.
The mp4 is hosted on dropbox which contains it's own player. I recorded it with my phone which does not have a webm record codec, and the file was too big to be attached in the bug itself. Thank you for the heads up though for the future.
Wow, sorry about the triple post...
OK, so it seems this is generic for all systems and not just SNA. I'll investigate when I have a bit of time.
A bit more info: Manually enabling Glamor in my 20-radeon.conf file seemed to get rid of the issue, though it is not a real solution as Glamor is buggy and not ideal. The issue seems to be present in both UXA and SNA codepaths.
*** Bug 738552 has been marked as a duplicate of this bug. ***
I chatted with Chris Wilson a bit about this today. The theory goes something like this... When the overlay window is unmapped, its contents are supposed to be copied to the root window, but aren't for some reason, so any time the root window peeks through, we show what was on the root window when the X server was started. You can test this theory by running xsetroot -background magenta. If you start seeing magenta instead of the plymouth screen, then the flash is from the root window. Aside from the copy not working, it's not clear why the root window peeks through on VT switches. mutter used to set the root window to black, which mitigated this issue somewhat (black flicker is less noticeable). There's an open bug to have mutter set the root window to the noise texture (bug 740377), which will also look bad in this situation. Anyway, still more investigation needs to be done to figure out why things are going wrong in the X server.
(In reply to comment #14) > When the overlay window is unmapped, its contents are supposed to > be copied to the root window Huh? The overlay window and root window's backing pixmap are the same. The overlay window isn't redirected -- that's sort of the point of it.
Hi, > Huh? The overlay window and root window's backing pixmap are the same. The > overlay window isn't redirected -- that's sort of the point of it. You're right that mutter would never redirect the overlay window. I don't even think clients can redirect the overlay window. It doesn't even make sense, since the overlay window is the destination of the composited output, not a source to copy from. But, I believe the composite overlay window has an RGB visual and the stage window uses an RGBA visual. This, I believe triggers "automatic" redirection of the stage window in the X server implicitly. Though, I guess that's not relevant, since that's the stage window and not the overlay window. Furthermore what you're saying is scan out happens from the root window pixmap, so fundamentally if the pixels are ending up on screen then they're making it to the root window pixmap. So the theory in comment 14 doesn't pass muster. Still, it seems like we're seeing a pristine view of the root window without any inferior drawing on it, so a copy of it must be stashed somewhere somehow. I guess we need to do more digging. I guess one thing we should do is try the xsetroot -background magenta and see if the flicker turns magenta.
okay new theory. The pixel buffer used for backing the root window, gets discarded on vt exit, and the root window is assigned a new buffer on vt enter. if the root window is back pixmap None, then the contents of that buffer (that contains stale content from plymouth or other X servers or whatever) will briefly flash on screen until overlay window is redrawn. people see it on reboot if they use user switching, because the first X server jumps to the second X server's VT when the first X server exits.
comment 17 turns out to be wrong. the buffer used for backing the root window remains in tact on vt switches, and (the intel driver at least) carefully initializes all buffers before displaying them. One problem (going from GDM -> user session) turns out to be an issue with Present. If the screen is about to flip buffers and the overlay window is destroyed, then the code tries to abort the flip and instead copy the new buffer to the old buffer. This fails since the overlay window is already destroyed, and the copy destination is the overlay window drawable. Chris Wilson posted a patch here: https://bugzilla.gnome.org/show_bug.cgi?id=737226#c15 to do the copy in a way that will succeed even though the overlay window is gone (or something like that). There's probably some other related issue causing the copy to fail on vt switch (say the copy happens when the X server temporarily sets the root clip to 0 to force app redraws, so the copy becomes a noop). needs more investigation.
I still see this issue, but in my case it only affects leftover ttys. They only contain sensible data if I didn't log out on them before.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.