It was found that 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, making no longer possible to start and stop daemons or cleanly reboot the system. Inetd-style services managed by systemd no longer accept connections. Since the notification socket, /run/systemd/notify, is world-writable, this allows a local user to perform a denial-of-service attack against systemd. PoC: NOTIFY_SOCKET=/run/systemd/notify systemd-notify "" Upstream bug report: https://github.com/systemd/systemd/issues/4234 CVE request: http://www.openwall.com/lists/oss-security/2016/09/28/9
Created systemd tracking bugs for this issue: Affects: fedora-all [bug 1380287]
This fix was applied upstream: https://github.com/systemd/systemd/commit/531ac2b2349da02acc9c382849758e07eb92b020 Upstream bug also indicates that the problem was likely introduced via this change, added in v219: https://github.com/systemd/systemd/commit/d875aa8ce10b458dc218c0d98f4a82c8904d6d03
Additional upstream fixes: https://github.com/systemd/systemd/commit/9987750e7a4c62e0eb8473603150596ba7c3a015 https://github.com/systemd/systemd/commit/8523bf7dd514a3a2c6114b7b8fb8f308b4f09fc4 The second commit reverts the original fix linked in comment 3.
References: https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_tweet
CVE-2016-7796 was moved to a separate bug 1381911, as those CVEs affect different systemd versions. Only the fix for CVE-2016-7796 make the assert causing CVE-2016-7795 reachable.
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2016:2610 https://rhn.redhat.com/errata/RHSA-2016-2610.html
This issue has been addressed in the following products: Red Hat Enterprise Linux 7.2 Extended Update Support Via RHSA-2016:2694 https://rhn.redhat.com/errata/RHSA-2016-2694.html