systemd fails an assertion in manager_invoke_notify_message when
a zero-length message is received over its notification socket.
After failing the assertion, PID 1 hangs in the pause system call.
It is no longer possible to start and stop daemons or cleanly reboot
the system. Inetd-style services managed by systemd no longer accept
Since the notification socket, /run/systemd/notify, is world-writable,
this allows a local user to perform a denial-of-service attack against
NOTIFY_SOCKET=/run/systemd/notify systemd-notify ""
This vulnerability is present in all versions of systemd since at
This has been reported to systemd.
There's still some chatter on this upstream. I'm waiting a bit to see if this PR gets merged.
Backporting the fix(es) to systemd-226 is non-trivial.
system-231 has some regressions, the fixes for which are also non-trivial backports.
I would prefer to wait for upstream to release systemd-232 to resolve this.
The PR was merged and first release containing the fix was =sys-apps/systemd-232 which already landed in the Gentoo repository: https://gitweb.gentoo.org/repo/gentoo.git/commit/sys-apps/systemd?id=1aac346933936be0fca1b24cac3ba2a147b08c6f
@ maintainer(s): Please tell us how to proceed. Is systemd-232 ready for stabilization?
(In reply to Thomas Deutschmann from comment #4)
> @ maintainer(s): Please tell us how to proceed. Is systemd-232 ready for
No, systemd-232 introduced additional regressions and is not fit for stabilization.
See bug 598992, bug 599152.
Maintainer(s), please advise if you are ready for stabilization or call for stabilization yourself.
Let's proceed with systemd-233-r1.
I have taken the liberty of adding sys-libs/libseccomp to the package list to satisfy a dependency.
Stable on alpha.
arm should now stabilize 233-r2 instead (bug 622874).
GLSA Vote: No