<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Le 3/08/20 à 12:46, Laurent Bigonville
a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:a0b9edd4-9414-4bc1-dac7-214b1e48fd61@debian.org">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
On Sun, 2 Aug 2020 22:08:56 +0200 Mart van de Wege <a
class="moz-txt-link-rfc2396E" href="mailto:mart@vdwege.eu"
moz-do-not-send="true"><mart@vdwege.eu></a> wrote:<br>
> On Sun, 2 Aug 2020 21:59:05 +0200<br>
> Michael Biebl <a class="moz-txt-link-rfc2396E"
href="mailto:biebl@debian.org" moz-do-not-send="true"><biebl@debian.org></a>
wrote:<br>
> <br>
> > Am 02.08.20 um 21:41 schrieb Mart van de Wege:<br>
> > > Package: systemd<br>
> > > Version: 245.7-1<br>
> > > Severity: normal<br>
> > > <br>
> > > With SELinux enabled (booting with selinux=1
security=selinux), as<br>
> > > soon as systemd wants to clean up
/run/user/<UID> for a session,<br>
> > > the kernel will oops, leaving the
systemd-user-runtime-dir process<br>
> > > that's trying to clean up the directory in an
uninterruptible sleep<br>
> > > (D) state. <br>
> > <br>
> > I fail to see how this is a systemd bug. This looks more
like a kernel<br>
> > and/or Selinux issue to me.<br>
> > <br>
> You have a point there. I selected systemd because it at
first appeared<br>
> to be a systemd bug (process hangs), but of course, if it
causes an<br>
> oops reliably with selinux enabled (which it does), it should
be<br>
> retargeted to those packages.<br>
> <br>
> Is that still possible, or should we close this one and let
me refile?<br>
<p>Before closing the bugs, could you confirm that you are running
SELinux in permissive mode or not (for what I can see in the
logs it seems to be the case)?</p>
<p>On one of my machine at home, I had a similar issue where the
shutdown/reboot is blocked by systemd-user-runtime-dir and I'm
certainly running in permissive mode on that machine. But on
other machines it was not happening, I was planning to
investigate more, but ENOTIME<br>
</p>
<p>Permissive mode shouldn't deny anything, just log what would be
denied by SELinux. So the bug could be either in the kernel or
in libselinux (systemd shouldn't be aware that anything would be
denied). And indeed I see the following BUG in the provided
logs:</p>
<pre class="message">Aug 02 21:05:37 galahad kernel: BUG: kernel NULL pointer dereference, address: 0000000000000060
</pre>
Are you running the latest available kernel?<br>
</blockquote>
<br>
Actually I can reproduce this with 5.7.10 (which is the latest
available kernel in debian). I would reassign to the kernel, but
this looks more like a problem with the audit framework than a
problem with SELinux itself if I can trust the trace in dmesg<br>
</body>
</html>