In systemd 259, systemd-journald can send ANSI escape sequences to the terminals of arbitrary users when a "logger -p emerg" command is executed, if ForwardToWall=yes is set.

In systemd 260 before 261, a local unprivileged user can trigger an assert via an IPC API call with an array or map that has a null element.

In nspawn in systemd 233 through 259 before 260, an escape-to-host action can occur via a crafted optional config file.

In udev in systemd before 260, local root execution can occur via malicious hardware devices and unsanitized kernel output.

In systemd 259 before 260, there is local privilege escalation in systemd-machined because varlink can be used to reach the root namespace.

In systemd 258 before 260, a local unprivileged user can trigger an assert when a Delegate=yes and User=<unset> unit exists and is running.

A race condidition in systemd-coredump allows a local attacker to crash a SUID program and gain read access to the resulting core dump

A vulnerability was found in systemd-resolved. This issue may allow systemd-resolved to accept records of DNSSEC-signed domains even when they have no signature, allowing man-in-the-middles (or the upstream DNS resolver) to manipulate records.

DISPUTED An issue was discovered in systemd 253. An attacker can modify a sealed log file such that, in some views, not all existing and sealed log messages are displayed. NOTE: the vendor reportedly sent "a reply denying that any of the finding was a security vulnerability."

DISPUTED An issue was discovered in systemd 253. An attacker can truncate a sealed log file and then resume log sealing such that checking the integrity shows no error, despite modifications. NOTE: the vendor reportedly sent "a reply denying that any of the finding was a security vulnerability."

DISPUTED An issue was discovered in systemd 253. An attacker can modify the contents of past events in a sealed log file and then adjust the file such that checking the integrity shows no error, despite modifications. NOTE: the vendor reportedly sent "a reply denying that any of the finding was a security vulnerability."

systemd before 247 does not adequately block local privilege escalation for some Sudo configurations, e.g., plausible sudoers files in which the "systemctl status" command may be executed. Specifically, systemd does not set LESSSECURE to 1, and thus other programs may be launched from the less program. This presents a substantial security risk when running systemctl from Sudo, because less executes as root when the terminal size is too small to show the complete systemctl output.

A vulnerability was found in systemd. This security flaw can cause a local information leak due to systemd-coredump not respecting the fs.suiddumpable kernel setting.

systemd 250 and 251 allows local users to achieve a systemd-coredump deadlock by triggering a crash that has a long backtrace. This occurs in parseelfobject in shared/elf-util.c. The exploitation methodology is to crash a binary calling the same function recursively, and put it in a deeply nested directory to make its backtrace large enough to cause the deadlock. This must be done 16 times when MaxConnections=16 is set for the systemd/units/systemd-coredump.socket file.

An off-by-one Error issue was discovered in Systemd in formattimespan() function of time-util.c. An attacker could supply specific values for time and accuracy that leads to buffer overrun in formattimespan(), leading to a Denial of Service.

A use-after-free vulnerability was found in systemd. This issue occurs due to the onstreamio() function and dnsstreamcomplete() function in 'resolved-dns-stream.c' not incrementing the reference counting for the DnsStream object. Therefore, other functions and callbacks called can dereference the DNSStream object, causing the use-after-free when the reference is still used later.

A flaw was found in systemd. An uncontrolled recursion in systemd-tmpfiles may lead to a denial of service at boot time when too many nested directories are created in /tmp.

A flaw was found in systemd. Attacker controlled alloca() in function unitnamepathescape() leads to a crash in systemd and ultimately a kernel panic. Systemd parses the content of /proc/self/mountinfo and each mountpoint is passed to mountsetupunit(), which calls unitnamepathescape() underneath to duplicate the string through alloca(). A local attacker who is able to mount a filesystem on a very long path can crash systemd and the whole system.

Upstream PR: https://github.com/systemd/systemd/pull/20256

Upstream commit: https://github.com/systemd/systemd/pull/20256/commits/441e0115646d54f080e5c3bb0ba477c892861ab9

An exploitable denial-of-service vulnerability exists in Systemd 245. A specially crafted DHCP FORCERENEW packet can cause a server running the DHCP client to be vulnerable to a DHCP ACK spoofing attack. An attacker can forge a pair of FORCERENEW and DCHP ACK packets to reconfigure the server.

systemd could allow a local authenticated attacker to gain elevated privileges on the system, caused by the mishandling of numerical usernames. By sending a specially-crafted request, an attacker could exploit this vulnerability to gain elevated privileges as root.

A heap use-after-free vulnerability was found in systemd before version v245-rc1, where asynchronous Polkit queries are performed while handling dbus messages. A local unprivileged attacker can abuse this flaw to crash systemd services or potentially execute code and elevate their privileges, by sending specially crafted dbus messages.

An issue was discovered in buttonopen in login/logind-button.c in systemd before 243. When executing the udevadm trigger command, a memory leak may occur.

DISPUTED systemd 239 through 245 accepts any certificate signed by a trusted certificate authority for DNS Over TLS. Server Name Indication (SNI) is not sent, and there is no hostname validation with the GnuTLS backend. NOTE: This has been disputed by the developer as not a vulnerability since hostname validation does not have anything to do with this issue (i.e. there is no hostname to be sent).

An improper authorization flaw was discovered in systemd-resolved in the way it configures the exposed DBus interface org.freedesktop.resolve1. An unprivileged local attacker could call all DBus methods, even when marked as privileged operations. An attacker could abuse this flaw by changing the DNS, Search Domain, LLMNR, DNSSEC and other network link settings without any authorization, allowing control of the network names resolution process and cause the system to communicate with wrong or malicious servers.

systemd 242 changes the VT1 mode upon a logout, which allows attackers to read cleartext passwords in certain circumstances, such as watching a shutdown, or using Ctrl-Alt-F1 and Ctrl-Alt-F2. This occurs because the KDGKBMODE (aka current keyboard mode) check is mishandled.

In systemd before v242-rc4, it was discovered that pamsystemd does not properly sanitize the environment before using the XDGSEAT variable. It is possible for an attacker, in some particular configurations, to set a XDGSEAT environment variable which allows for commands to be checked against polkit policies using the "allowactive" element rather than "allowany".

It was discovered that a systemd service that uses DynamicUser property can get new privileges through the execution of SUID binaries, which would allow to create binaries owned by the service transient group with the setgid bit set. A local attacker may use this flaw to access resources that will be owned by a potentially different service in the future, when the GID will be recycled.

It was discovered that a systemd service that uses DynamicUser property can create a SUID/SGID binary that would be allowed to run as the transient service UID/GID even after the service is terminated. A local attacker may use this flaw to access resources that will be owned by a potentially different service in the future, when the UID/GID will be recycled.

An issue was discovered in sd-bus in systemd 239. busprocessobject() in libsystemd/sd-bus/bus-objects.c allocates a variable-length stack buffer for temporarily storing the object path of incoming D-Bus messages. An unprivileged local user can exploit this by sending a specially crafted message to PID1, causing the stack pointer to jump over the stack guard pages into an unmapped memory region and trigger a denial of service (systemd PID1 crash and kernel panic).

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.