Уязвимость функции dns_packet_new системного сервиса system-resolved менеджера Systemmd операционной системы Linux, позволяющая нарушителю выполнить произвольный код

Уязвимость службы анализирования имен пользователей демона Systemd, существующая из-за недостаточной проверки входных данных, позволяющая нарушителю запустить службу с root-привилегиями

Уязвимость демона Systemd, связанная с одновременным использованием общего ресурса и ошибками синхронизации, позволяющая нарушителю вызвать отказ в обслуживании

Уязвимость программы systemd-tmpfiles демона Systemd, позволяющая нарушителю обойти существующие ограничения доступа и раскрыть защищаемую информацию

systemd v233 and earlier fails to safely parse usernames starting with a numeric digit (e.g. "0day"), running the service in question with root privileges rather than the user intended.

In systemd 223 through 235, a remote DNS server can respond with a custom crafted DNS NSEC resource record to trigger an infinite loop in the dns_packet_read_type_window() function of the 'systemd-resolved' service and cause a DoS of the affected service.

systemd-tmpfiles in systemd before 237 attempts to support ownership/permission changes on hardlinked files even if the fs.protected_hardlinks sysctl is turned off, which allows local users to bypass intended access restrictions via vectors involving a hard link to a file for which the user lacks write access, as demonstrated by changing the ownership of the /etc/passwd file.

systemd-resolved through 233 allows remote attackers to cause a denial of service (daemon crash) via a crafted DNS response with an empty question section.

In systemd through 233, certain sizes passed to dns_packet_new in systemd-resolved can cause it to allocate a buffer that's too small. A malicious DNS server can exploit this via a response with a specially crafted TCP payload to trick systemd-resolved into allocating a buffer that's too small, and subsequently write arbitrary data beyond the end of it.

In systemd prior to 234 a race condition exists between .mount and .automount units such that automount requests from kernel may not be serviced by systemd resulting in kernel holding the mountpoint and any processes that try to use said mount will hang. A race condition like this may lead to denial of service, until mount points are unmounted.

It was discovered systemd does not correctly check the content of PIDFile files before using it to kill processes. When a service is run from an unprivileged user (e.g. User field set in the service file), a local attacker who is able to write to the PIDFile of the mentioned service may use this flaw to trick systemd into killing other services and/or privileged processes. Versions before v237 are vulnerable.

systemd-sysv-install ROOT overquoting

having upgraded from 230 or 231 to 234, NFS is not unmounted when halting

create static device inodes for SysV init

Wrong order in PATH env variable