[RESPONDED] Fedora 37: Can't log back in after suspend

Framework Laptop 13 Linux
1

I closed the lid which is set to the Suspend action on Fedora 37 and and when I opened it again, although I was able to move the cursor I couldn’t focus the the input box to enter my login nor was the fingerprint reader working.

So I turned the computer off.

Now I have a SELinux error message window telling me the check process attempted to use mmap_zero

SELinux is preventing check from mmap_zero access on the memprotect labeled spc_t.

*****  Plugin mmap_zero (53.1 confidence) suggests   *************************

If you do not think check should need to mmap low memory in the kernel.
Then you may be under attack by a hacker, this is a very dangerous access.
Do
contact your security administrator and report this issue.

*****  Plugin catchall_boolean (42.6 confidence) suggests   ******************

If you want to allow mmap to low allowed
Then you must tell SELinux about this by enabling the 'mmap_low_allowed' boolean.

Do
setsebool -P mmap_low_allowed 1

*****  Plugin catchall (5.76 confidence) suggests   **************************

If you believe that check should be allowed mmap_zero access on memprotect labeled spc_t by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'check' --raw | audit2allow -M my-check
# semodule -X 300 -i my-check.pp

Additional Information:
Source Context                system_u:system_r:spc_t:s0
Target Context                system_u:system_r:spc_t:s0
Target Objects                Unknown [ memprotect ]
Source                        check
Source Path                   check
Port                          <Unknown>
Host                          framework
Source RPM Packages           
Target RPM Packages           
SELinux Policy RPM            selinux-policy-targeted-37.19-1.fc37.noarch
Local Policy RPM              container-selinux-2.205.0-1.fc37.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     framework
Platform                      Linux framework 6.2.7-200.fc37.x86_64 #1 SMP
                              PREEMPT_DYNAMIC Fri Mar 17 16:16:00 UTC 2023
                              x86_64 x86_64
Alert Count                   15
First Seen                    2023-03-26 16:05:40 CEST
Last Seen                     2023-03-26 16:05:40 CEST
Local ID                      09dd39a0-2545-482e-83ae-9a23e5e3e1b6

Raw Audit Messages
type=AVC msg=audit(1679839540.892:305): avc:  denied  { mmap_zero } for  pid=1473 comm="check" scontext=system_u:system_r:spc_t:s0 tcontext=system_u:system_r:spc_t:s0 tclass=memprotect permissive=0


Hash: check,spc_t,spc_t,memprotect,mmap_zero
1 Like
2

This feels like it may be a mis-configured SELinux policy and mmap. Have you made any changes to your default SELinux policies? Looks like a process attempted to map memory and SELinux said nope. I know this doesn’t happen on a vanilla installation (that I’ve ever experienced that is).

Walk us through the steps or events that brought you to this state? A guide you tried, new policies setup, update to related software affecting these changes, etc? It could even be oddball changes to power states, but I lean more with the policy changes as a likely culprit. I’ll know more as you fill us in on the details.

Also tagging @Loell_Framework in this one as well if you have any other thoughts.

3

I realize I have been trying to switch DEs and that may be the source of the issue ?

I remember someone saying that switching DEs was a source of issues but I decided to trust the link below.

This page says it’s easy to switch DEs so I gave it a try and indeed it was. I started with the GNOME spin first then KDE and settled on Cinnamon.

Yesterday, I closed the lid and the computer never woke up, there was a black screen and the power button light fading in and out. But I did not even get an error after rebooting.

I suppose the check process that tried to access sth it could not is part of the login manager because I don’t see it listed in my processes right now

4

Hi @a_framework_owner ,

can you perhaps try

sudo restorecon -rv /

that command could likely fix SElinux issues, note that it takes a while to run and finish, let us know if it somehow fixes your issue or not, or the error message may change.

1 Like
5

Thank you for your answer.

Sadly I have has that SELinux report again since. However, this time it was not linked to an inability to log in.
In the end I don’t mind much the reports, they’re no really frequent. I mind a little more not being able to log back in although it only happened twice so far.

Can you confirm the check process that’s being reported about is part of the log in procedure ?

Anyways, I’ll probably back up my home directory and reinstall when I have the time. Thanks for trying.

6

Between KDE and Gnome pretty odd stuff. Usually I see oddness on users with a dedicated home and shared desktop environments. However, SELinux are a completely different issue.

I’d start fresh, with a clean install after you’ve backed up your home data. Try again and see if the issue presents itself again.

1 Like
7

For the purpose of documentation:

If you see a black screen when opening the lid after a close, the login interface does appear if you wait something like 15 seconds.

8

…after pressing the power button.

9

Seeing the same error after installing Docker on Fedora

10

Interesting. I do have docker installed too.
I also have regularly SelLinux errors about mmap. Do you have anything like that ?

11

Fedora 40?