Stories
Slash Boxes
Comments

SoylentNews is people

Systemd Crashing Bug

posted by CoolHand on Wednesday October 05 2016, @12:46AM   Printer-friendly
from the love-for-lennart dept.

mechanicjay writes:

Security researcher and MateSSL founder, Andrew Ayer has uncovered a bug which will either crash or make systemd unstable (depending on who you talk to) on pretty much every linux distro. David Strauss posted a highly critical response to Ayer. In true pedantic nerd-fight fashion there is a bit of back and forth between them over the "true" severity of the issue and what not.

Nerd fights aside, how you feel about this bug, will probably largely depend on how you feel about systemd in general.

The following command, when run as any user, will crash systemd:

NOTIFY_SOCKET=/run/systemd/notify systemd-notify ""

After running this command, PID 1 is hung in the pause system call. You can no longer start and stop daemons. inetd-style services no longer accept connections. You cannot cleanly reboot the system. The system feels generally unstable (e.g. ssh and su hang for 30 seconds since systemd is now integrated with the login system). All of this can be caused by a command that's short enough to fit in a Tweet.

Edit (2016-09-28 21:34): Some people can only reproduce if they wrap the command in a while true loop. Yay non-determinism!

Original Submission

 
This discussion has been archived. No new comments can be posted.
Systemd Crashing Bug | Log In/Create an Account | Top | 69 comments | Search Discussion
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

  • (Score: 5, Funny) by DECbot on Wednesday October 05 2016, @03:14PM

    by DECbot (832) on Wednesday October 05 2016, @03:14PM (#410634) Journal

    You know, I think it would be even better if Poettering instead of patching this bug shows his programming chops by adding a new module to systemd called inputd. Inputd would be responsible for sanitizing all standard input before passing it to the application reading standard input. And when an application reads input from inputd, it can pass a bunch of asinine arguments to inform inputd of what the sanitized input should look like.

    Likewise, we can have an outputd that will sanitize the standard output, so you can turn on all the DEBUG flags, make the kernel spit out garbage, but sanitize the output before you send it over to the logs so no one knows you left the debug flags on.

    --
    cats~$ sudo chown -R us /home/base
    Starting Score:    1  point
    Moderation   +3  
       Interesting=1, Funny=2, Total=3
    Extra 'Funny' Modifier   0  
    Karma-Bonus Modifier   +1  
    Total Score:   5  

  • (Score: 0) by Anonymous Coward on Sunday October 09 2016, @01:35PM

    by Anonymous Coward on Sunday October 09 2016, @01:35PM (#412052)

    They do have a dev involved that was working on a user space tty implementation...