https://www.theregister.co.uk/2018/10/26/systemd_dhcpv6_rce/ (nice title)
https://news.slashdot.org/story/18/10/27/196227/new-systemd-vulnerability-discovered
What worries me is how silly the buffer length has been treated ...
from if (*buflen < len)
to if (*buflen < offsetof(DHCP6Option, data) + len)
This isn't about init system and unix philosophy, it's plain bad
Systemd is not only init for a very long time.
Systemd is slowly swallowing things around it which are on boundary between kernel and user programs, or are just often used services, or must have things which does not belong to kernel....
In this way making systemd some kind of a system which you will use to do anything.
With this mindset and philosophy, How can it be safe and stable ?
Also keep in mind that problems will become more and more complex.
The systemd-networkd code is horrifically bad. There's that blog post rant (https://blog.erratasec.com/2018/10/systemd-is-bad-parsing-and-should-feel.html) that's been going around, and I agree with the author although the assert_return macro doesn't really bother me as much (it's just a misleading name). The silver lining here is that not even systemd users use systemd-networkd, but it still doesn't change the fact that the design is flat out horrible.
SystemD is perfect example of "How to not do it".
to me this code looks totally confused, assume len is an unsigned int or unsigned small int.. why does it not trigguer an error with the compiler.
Does this affect artix as i use startx ?
Artix is non-systemd, so it should be a non-issue here.
Best regards.