Cinnamon Screensaver (lock screen) sometimes does not prompt for password, and sometimes freezes system

Bug #1652489 reported by flan_suse on 2016-12-25
This bug affects 18 people
Affects Status Importance Assigned to Milestone

Bug Description

After installing the latest updates on December 23, 2016, the cinnamon-screensaver (AKA "lock screen") sometimes will not require a password to unlock! Anyone can bypass the lock screen due to this critical bug. Another issue after installing these updates is that locking the session can sometimes freeze the entire system, which will require a hard reboot or the "Sys Resc RSEISUB" key combination.

It matters not if locking the session from the menu, keyboard shortcut, or suspending the system to RAM. Same issue exists with these recent updated packages.

Here is the forum post as a reference:

========== SYSTEM INFORMATION ==========
Linux Mint 18.1 Cinnamon

========== UNAME -A ==========
4.4.0-57-generic #78-Ubuntu SMP Fri Dec 9 23:50:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

========== INXI -G ==========
Graphics: Card: Intel 3rd Gen Core processor Graphics Controller
           Display Server: X.Org 1.18.4 drivers: intel (unloaded: fbdev,vesa) Resolution: 1920x1080@60.00hz
           GLX Renderer: Mesa DRI Intel Ivybridge Mobile GLX Version: 3.0 Mesa 11.2.0

========== APT HISTORY ==========
Commit Log for Fri Dec 23 09:01:26 2016

Upgraded the following packages:
cinnamon (3.2.6+serena) to 3.2.7+serena
cinnamon-common (3.2.6+serena) to 3.2.7+serena
cinnamon-screensaver (3.2.9+serena) to 3.2.12+serena
cinnamon-screensaver-x-plugin (3.2.9+serena) to 3.2.12+serena
libcscreensaver0 (3.2.9+serena) to 3.2.12+serena
mdm (2.0.16+serena) to 2.0.17+serena

Installed the following packages:
cinnamon-screensaver-pam-helper (3.2.12+serena)

flan_suse (flansuse) on 2016-12-25
description: updated
information type: Private Security → Public Security
description: updated
Jerrylove7 (jerrylove7) wrote :


aaime (andrea-aime) wrote :

Happens here too... quite worrying, I basically have to shut down the machine if kids are around in the house.

Omar Trigui (omar-nvidia-tr) wrote :

Same here, the "lock screen" button in the Menu doesn't lock the session.
Os : Mint 18.1 ( Upgraded from Mint 18 )

flan_suse (flansuse) on 2016-12-28
description: updated
rewind (ttanev) wrote :

Happens here as well, upgrade from 18 -> 18.1 (Asus U38N). Ctrl+Alt+L does nothing, as well as the "Lock screen" button from the main menu. After waiting the required time for the screen saver to kick in (and the "lock delay") the display(s) goes dark, however the hitting a key of moving the mouse is enough to "unlock".

flan_suse (flansuse) wrote :

An update was just released on the repositories! Check your update manager, use apt, or Synaptic to refresh, download, and install the update! So far so good, as it appears to be working like normal again! :)

I went ahead and rebooted my system after updating, just to make sure.

========== APT HISTORY ==========
Upgraded the following packages:
cinnamon-screensaver (3.2.12+serena) to 3.2.13+serena
cinnamon-screensaver-pam-helper (3.2.12+serena) to 3.2.13+serena
cinnamon-screensaver-x-plugin (3.2.12+serena) to 3.2.13+serena
libcscreensaver0 (3.2.12+serena) to 3.2.13+serena

Omar Trigui (omar-nvidia-tr) wrote :

The fix is confirmed with the update 3.2.13+serena.

flan_suse (flansuse) wrote :

Okay, now it seems that even though the screen will prompt for a password, sometimes resuming from suspend will allow access to the desktop for a few seconds, and THEN it will prompt for a password. This is the least secure lock screen I have seen to date. Why can't it just operate like any of the other lock screen methods from GNOME, Xfce, KDE, and so on?

Dave (davenue) wrote :

The update did not resolve the issue for me. I still have to `kill pid` on cinnamon-screensaver via ssh to get a functional/responsive desktop after waking from suspend.

Michael Webster (miketwebster) wrote :

If on 3.2.13, can you kill cinnamon-screensaver (sudo killall cinnamon-screensaver) then run 'cinnamon-screensaver --debug'

Try to reproduce this issue, the report back any output you get from the terminal. Thanks

Dave (davenue) wrote :

Done. Will report back if reproduced. Thanks

rewind (ttanev) wrote :

Experiencing the same issue as Dave (davenue), sometimes after unsuspending I get directly to desktop without any cinnamon-screensaver running.

I've started a `cinnamon-screensaver --debug &>~/cinnamon-screensaver-debug.log` as well and will report back once the issue is reproduced.

Michael Webster (miketwebster) wrote :

Do either of you have more than one keyboard layout installed (meaning, you get the little flag or layout icon on the left side of the password box?)

flan_suse (flansuse) wrote :

"Do either of you have more than one keyboard layout installed"

I do not. I am using the default keyboard layout and settings.

I am not sure if the bugs are all related, but in my case, I will gain access to the desktop for 5 to 10 seconds (sometimes!) and then it will lock the screen. On previous distros and different desktop environments, the lock was immediate. However, with this current issue, sometimes the locking is delayed. (Previous version of cinnamon-screensaver, it sometimes would not lock at all.)

I am running it in --debug and will copy + paste the results if it happens again. Just need to make sure not private information shows up in the debug output. ;) I tried using "tee" to dump it into a text file, but that doesn't seem to work.

rewind (ttanev) wrote :

To Michael Webster - Yes, I have two keyboard layouts installed. By the way, not sure if this is related, just as a side note - yesterday I unlocked my account without changing to English layout with flag showing Bulgarian (the password is not in Bulgarian, this is certain).

Just reproduced the issue, the log is attached. As stated above the log was collected by issuing `cinnamon-screensaver --debug &>~/cinnamon-screensaver-debug.log` until couple of minutes ago when I unlocked my workstation just by moving the mouse.

rewind (ttanev) wrote :

A note on reproduction:
- configure any application that is using pulseaudio with firejail and attempt to use audio (e.g. skype alpha with notification sounds)
- pulseaudio enters in infinite loop when anoother application (not jailed) tries to use audio as well (e.g. an audio/movie player) - related pulseaudio bugreport here -
- At this point cinnamon-screensaver is getting into the state from the log above (complaining with 'shm_open() failed: Too many open files') and the workstation gets unlocked without password.

I wasn't sure if these three are connected, however after reading here:

...turned out firejail would not work with pulseaudio until version 9.0 (Mint 18.1/Ubuntu 16.04 is with 8.0)

Possible workaround for now is to not use firejail with an application that uses audio, tried this for couple of days without further issues with cinnamon-screensaver.

flan_suse (flansuse) wrote :

As of now, latest updates, I still have the random issue where resuming from suspend will allow me to interact with my session for about 5 to 10 seconds before the lock screen kicks in and prompts for a password.

Kevin Moore (kevinwebx) wrote :

I am having the same issue. Any update for this? I've updated my system and everything is up to date, but still have the same issue. It doesn't ask for a password on a screen lock. Just opens the screen straight away. I've been using Linux Mint for almost 4 years and this is the first time I've had an issue like this.

Laurent B (l-ubuntu-r) wrote :

After the recent upgrade, I could not lock screen at all.
In my case, I found the cause. It may or may not be related to other reports, since for me, there was no freeze nor late lock.
My user is in the 'nopasswdlogin' group, so per the mdm PAM configuration, it allows to log in graphically by a single click on the user name. Until recently, *only* that was allowed, ie, once logged in, I could still lock the screen, and once locked, a password was needed.
Since the last update, locking the session was not possible. As soon as I removed the user from the group, it worked again. I checked that it's still only the mdm PAM using that group.

I think the change of behaviour is confusing, and not a right choice, as logging in and locking the screen are two different things.

flan_suse (flansuse) wrote :

How Linux Mint (AKA Cinnamon) locks the current session needs to be redon from scratch in my opinion. This is much too glitchy and unreliable for something as essential and crucial as locking a user's screen. My guess is the code for the cinnamon-lockscreen is too complex for what *any* OS and *any* desktop environment lock screen should do, and do SIMPLY.

Michael Webster (miketwebster) wrote :

It was just entirely redone, this is why there are issues. We went from a 20-year-old codebase which was beginning to have serious issues with compatibility to a completely new codebase. There will be bugs. There have also been a ton of fixes since the last version release, including most likely the issue you're having. Feel free try the version in git and provide feedback, I'm not sure there will be another point release before the next main release.

flan_suse (flansuse) wrote :

Do you mean that users of Linux Mint 18.x will not receive the version that contains such fixes, even as a patch? It's a major security issue, and can likewise deal great instability. This isn't just an aesthetic thing. Access that bypasses a lockscreen (even if only temporary) is something way to critical to be fixed in a version release.

Doug Harple (dharple) wrote :


I'm seeing this issue as well (the screensaver doesn't lock) on a fresh install. Prior to this install, it was working OK.

I noticed the following in my .xsession-errors, and I believe it might shed some light on the issue:

error starting cinnamon-screensaver-pam-helper: Failed to execute child process "/usr/share/cinnamon-screensaver/pamhelper/cinnamon-screensaver-pam-helper" (No such file or directory)

I tried a reinstall of cinnamon-screensaver and cinnamon-screensaver-pam-helper, but it did not create that file or a symlink to it. I haven't dug in to the post install script, but I'll be happy to debug that if you need.

Doug Harple (dharple) wrote :

I should have added: I was last using Mint and Cinnamon about a month ago, and the lock was working correctly at that point. I just did a fresh reinstall of this box tonight, and I noticed the issue and the errors.

Doug Harple (dharple) wrote :

OK, so the issue that I reported went away with a reboot. (More than likely a restart of cinnamon will be sufficient.) I'll keep my eye out for any of the other issues reported.

Also, keep up the good work! The new screensaver is excellent. I love the integration with rhythmbox (and presumably any music player that shows up in the notification area).

rewind (ttanev) wrote :

Definitely agree that the new lock screen features worth the month long bug chasing after all, I like the music controls myself very much. Prior to this version of cinnamon-screensaver in case I forget to pause my player I often had to unlock the workstation to pause it or leave the player running, now it's just a click or keyboard shortcut away.

Just to confirm that the previous report is still in effect - without firejail-ed applications trying to produce audio everything seems fine and locking is working properly both after a fresh session lock or after an un-suspend.


flan_suse (flansuse) wrote :

Well, guess what? On version 3.2.13, I resumed from suspend, and I was never prompted for a password. In fact, as I am writing this comment, I've been using my computer since resuming from suspend... and still no password prompt.

Fully updated Linux Mint 18, cinnamon-screensaver 3.2.13.

Unfortunately, I didn't have it running in debug mode, so I have nothing to copy+paste into here.

rewind (ttanev) wrote :

@flan_suse, please do the following:

- check if the cinnamon-screensaver is actually running, most of the time when I was having this issue it was in endless loop - a simple `pgrep -lf cinnamon-screensaver` should do.
- if it is not running start it in debug mode with `cinnamon-screensaver --debug &>~/cinnamon-screensaver-debug.log`
- then make sure that it's actually working (e.g. lock the screen with ctrl+alt+l)

Then the next time you stumble upon the same issue you'd have a debug log to attach here, which has much higher value for fixing the issue (opposite to the rant above). :)


flan_suse (flansuse) wrote :

Checked, and yes, it is (and was) running. I have it logging to the debug.log file, and will update with a comment if it happens again.

lemile (lemile) wrote :

Find attached the log i got last night.
When i left my session locked i found it unlocked this morning and cinnamon-screensaver went off.
I had to reboot to bring it back.

It keeps happening since a few days. It really bothers me because of the security lack it brings.

cinnamon-screensaver 3.2.13
#44-Ubuntu SMP Fri Mar 3 15:27:17 UTC 2017
Linux username 4.8.0-41-generic #44-Ubuntu SMP Fri Mar 3 15:27:17 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Timo Mihaljov (a-timo) wrote :

It seems that cinnamon-screensaver is leaking file descriptors and crashes when
it hits the hard ulimit.

Here's my screensaver process:

    timomi@melanthos ~> ps 2592
     2592 ? Sl 0:32 cinnamon-screensaver

It has loads of open eventfd file descriptors (797 in fact):

    timomi@melanthos ~> lsof -p 2592 | grep eventfd | head -10
    cinnamon- 2592 timomi 4u a_inode 0,11 0 8064 [eventfd]
    cinnamon- 2592 timomi 6u a_inode 0,11 0 8064 [eventfd]
    cinnamon- 2592 timomi 7u a_inode 0,11 0 8064 [eventfd]
    cinnamon- 2592 timomi 9u a_inode 0,11 0 8064 [eventfd]
    cinnamon- 2592 timomi 10u a_inode 0,11 0 8064 [eventfd]
    cinnamon- 2592 timomi 19u a_inode 0,11 0 8064 [eventfd]
    cinnamon- 2592 timomi 20u a_inode 0,11 0 8064 [eventfd]
    cinnamon- 2592 timomi 21u a_inode 0,11 0 8064 [eventfd]
    cinnamon- 2592 timomi 22u a_inode 0,11 0 8064 [eventfd]
    cinnamon- 2592 timomi 24u a_inode 0,11 0 8064 [eventfd]

    timomi@melanthos ~> lsof -p 2592 | grep eventfd | wc -l

After locking the screen (with Ctrl+Alt+L) for a minute or so, the amount of
FDs grows has grown to 835.

    timomi@melanthos ~> lsof -p 2592 | grep eventfd | wc -l

The number of open FDs doesn't seem to grow when the screen is unlocked.

I restarted the screensaver with the hard ulimit for file handles set to 250,
locked the screen and waited for a couple of minutes. The screen unlocked on
the first event (I think I moved the mouse) with no password prompt and crashed
when I tried to lock the screen again.

Jerrylove7 (jerrylove7) wrote :

Fresh install of 18.1 and still when resuming from sleep the screen shows the previous session for a few seconds before the lock screen appears.

flan_suse (flansuse) wrote :

Attached is the debug log after allowing me to use the desktop for about 5 seconds before it prompted me for a password. I found nothing interesting in the log, but I haven't the eyes nor expertise for this.

Manuel Kraus (1-ubuntukne-f) wrote :

I have the same issues, Linux Mint 18.1 Serena, cinnamon-screensaver 3.2.13+serena.

Today I switched to xscreensaver, as an interim solution. Just disable (not uninstall) the Cinnamon Screensaver and install the xscreensaver, then configure and activate it. It works without any quirks so far.

A working screensaver is essential to provide access security.

Sorry, I don't have the time to help to debug this.

Just giving this heads up, that it is possible to be able to use the "old" xscreensaver along the Cinnamon one until things are solved.

Alan Masters (whattahellalan) wrote :

For me the screensaver freezes most of times, and also freezes when i lock the screen.

Luke Plant (spookylukey) wrote :

I found exactly the same thing - no matter how it started (manually or automatically), the lock screen did not lock or show the 'enter your password' dialog. Simply moving the mouse or pressing a key got me back to the desktop.

After restarting the machine, however, it seems to work (for now).

For me this happened from a fresh install for Linux Mint 18.1. However, in the session where I experienced these issues, I also did a system update, which looks like included updates to cinnamon and cinnamon-screensaver. I'm not sure whether the issues existed before this update.

So I'm guessing that this may been caused by some interaction between the running and the new versions of these packages. If this guess is correct, then installing new versions of these packages should come with some kind of warning about needing to reboot or logout.

F5 (f5) wrote :

The version of my cinnamon-screensaver si "3.2.13+serena" and I was still unable to log in after locking the screen. I tried all suggestions on this thread but the only think that worked for me was to install xscreensaver and use it as a default.

Orkhan Jafarov (explorador) wrote :

I have the same problem: Linux Mint 18.2 Cinnamon 64-bit doesn't prompt for a password after being suspended when I reopen the lid.

As was advised by @rewind, I logged cinnamon screensaver logs to the attached file. There are critical errors and failed assertions at the end of the log file.

One more thing: `cinnamon-screensaver --debug &>~/cinnamon-screensaver-debug.log` command ended with a `Segmentation fault`.

Hope this helps to find the problem and the solution.

Changed in cinnamon-project:
status: Unknown → New
Orkhan Jafarov (explorador) wrote :

I think this is the first time I participate in a bug report process, so forgive me if I just don't understand the procedure, but is anyone trying to fix it? This is a major security issue and its status hasn't been updated for over a month. Is there anything I can do to accelerate the investigation?


Please refer to for both issues (freezing and failure to lock the session).

no longer affects: linuxmint
Changed in cinnamon-project:
status: New → Unknown
Changed in cinnamon-project:
status: Unknown → New
flan_suse (flansuse) wrote :

Clem, I already had my options configured as you recommend in the github report. The issue of a temporarily unlocked session happens when resuming from suspend, even if suspending the system was manually invoked, such as with a hotkey.

1) Use computer
2) Hit suspend key or shortcut
3) Computer (supposedly) locks session, and then immediately suspends
4) Move mouse, press key, or press power button
5) Computer resumes from suspend and sometimes briefly allows access to an unlocked session
6) After a few seconds, session automatically relocks and prompts for a password

During step #5, everything is visible to unwanted eyes: icons, open windows and applications, etc

flan_suse, you're describing a separate issue altogether.

I had a look through the issues on github and couldn't find one for this, so please create a new one. It's probably an issue in either CSD (which should make sure CSR locks before telling the session to suspend), or CSR itself (which should hold until fully locked).

The fix we're preparing for this bug report (here) might help, because it will reduce the time it takes for CSR to lock on idle from 10 seconds to 0 seconds (we're getting rid of the fade-in basically). Still, this is definitely a separate issue.

Sorry.. I'm using acronyms.

- Please use github for mint projects, we follow it much more than Launchpad.
- CSR is the cinnamon-screensaver project
- CSD is cinnamon-settings-daemon (in particular here, we're talking about the power plugin for idle timeouts)
- CSM might be at play as well... cinnamon-session on github, cinnamon-session-manager historically.

flan_suse, I just checked with mtwebster, this was fixed in 3.4. It's not backportable due to codebase differences.

OK, the original issues (Freeze and failure to unlock due to fade-in) were fixed in 3.6.1 and 3.4.4.

Non-related issues were looked at as well, so I'll mention them briefly here as well:

- The fact that suspend didn't wait for the lock (resulting in the session being visible briefly on resume) was fixed in 3.4.
- Hotplug events (adding an external screen etc..) issues were addressed in 3.4.3.

Changed in cinnamon-project:
status: New → Fix Released
flan_suse (flansuse) wrote :

Posted at GitHub, I am going to post it here as well:

Forum post on the Mint forums, for reference:

I've managed to make one of the issues (not properly locking the screen when suspending the computer) **100% reproducible** on **Linux Mint 19 Cinnamon** with the following package versions:

cinnamon 3.8.8+tara

cinnamon-screensaver 3.8.2+tara

This might not address all the underlying causes, but it's a start! Perhaps the developers can use this to further investigate the code that needs to be rewritten. I will post this finding on the GitHub bug reports.

Here is how I can trigger this issue, and here is the text from **--debug** mode:

Calling XResetScreenSaver
manager: user activity, waking
manager: not locked, queueing idle deactivation
CsScreen dispose
CsScreen finalize
couldn't grab keyboard
couldn't grab keyboard
couldn't grab keyboard
couldn't grab keyboard
Nuking focus
couldn't grab keyboard
couldn't grab keyboard
couldn't grab keyboard
couldn't grab keyboard
couldn't grab mouse
couldn't grab mouse
couldn't grab mouse
couldn't grab mouse
Calling XResetScreenSaver

**Here is how I discovered a way to 100% reproduce this security issue:**

1) Make sure you have it set to lock the screen upon suspend and when the screensaver starts. Settings > Screensaver > Settings

2) Create a shortcut key / key combination for suspending the computer to RAM. If you have it set to suspend upon closing the lid, it will behave the same way if you follow the next steps.

3) Right-click somewhere, such as on the taskbar or a file or the desktop itself, in order to bring up a context menu. Do not do anything else with the mouse. Leave the cursor where it is.

4) Now close the laptop's lid. Wait a while, and you will hear the system go into suspend mode.

5) Now open the laptop's lid and you will hear the system wake up.

6) You have access to your entire unlocked session, completely bypassing any password dialogue or lock screen!

This can also be done via the shortcut keys, but it requires a more unlikely (though not improbable) timing of events. I had success exploiting the issue: if your press the shortcut key to suspend, and immediately bring up any context menu (or any such menu to steal the cursor's focus), you can reproduce the issue. However, the timing needs to be precise, so it's less likely to happen, yet it can still happen by mistake.

This still does not explain why there is a general degradation of Cinnamon over time, and why the screen locker gets slower and slower over time. They might be separate issues, or perhaps inter-related with this one. I hope this post helps the developers narrow down their search for the code responsible for this vulnerability.

Changed in cinnamon-project:
status: Fix Released → New
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.