Bug#966822: systemd: user-runtime-dir service crashes the kernel under SELinux

[Laurent Bigonville]

Le 3/08/20 à 12:46, Laurent Bigonville a écrit :
> On Sun, 2 Aug 2020 22:08:56 +0200 Mart van de Wege <mart at vdwege.eu> wrote:
> > On Sun, 2 Aug 2020 21:59:05 +0200
> > Michael Biebl <biebl at debian.org> wrote:
> >
> > > Am 02.08.20 um 21:41 schrieb Mart van de Wege:
> > > > Package: systemd
> > > > Version: 245.7-1
> > > > Severity: normal
> > > >
> > > > With SELinux enabled (booting with selinux=1 security=selinux), as
> > > > soon as systemd wants to clean up /run/user/<UID> for a session,
> > > > the kernel will oops, leaving the systemd-user-runtime-dir process
> > > > that's trying to clean up the directory in an uninterruptible sleep
> > > > (D) state.
> > >
> > > I fail to see how this is a systemd bug. This looks more like a kernel
> > > and/or Selinux issue to me.
> > >
> > You have a point there. I selected systemd because it at first appeared
> > to be a systemd bug (process hangs), but of course, if it causes an
> > oops reliably with selinux enabled (which it does), it should be
> > retargeted to those packages.
> >
> > Is that still possible, or should we close this one and let me refile?
>
> 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)?
>
> 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
>
> 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:
>
> Aug 02 21:05:37 galahad kernel: BUG: kernel NULL pointer dereference, address: 0000000000000060
>
> Are you running the latest available kernel?

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20200803/56e7fa8c/attachment.html>