On 2026-03-17 13:58:17, Michal Zalewski wrote: Nice work... flashbacks from 2002 (https://lcamtuf.coredump.cx/tmppaper.txt). It's frankly somewhat mind-boggling that distros keep a world-writable /tmp this day and age. Whatever questionable benefits it has, it also contributed to plenty of pointless and easily avoidable vulns. It's required by POSIX which, funny enough, forbids /tmp from being used the way snap-confine is using it. I wouldn't expect either of these projects to care about POSIX, but the same description was copied & pasted into the FHS. And to its credit, systemd has a page full of documentation on how to avoid this exact problem.
1. https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1chap10.html 2. https://refspecs.linuxfoundation.org/FHS3.0/fhs/ch03s18.html 3. https://systemd.io/TEMPORARYDIRECTORIES/
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."
systemd-coredump sets the sysctl fs.suiddumpable by default to 2 via a sysctl.d drop-in configuration file. For the kernel's builtin coredump handling this setting means that core dumps for setuid (or otherwise privileged) processes will be written to disk but will only be accessible to the root user to avoid sensitive data leaking to unprivileged user accounts. See also man 5 proc for the full documentation of this sysctl.
https://github.com/systemd/systemd/commit/b7641425659243c09473cd8fb3aef2c0d4a3eb9c
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.
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".
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).
A flaw was found in systemd-journald. An out-of-bounds read when parsing a crafted syslog message that could lead to information disclosure.
A flaw was found in systemd-journald. An uncontrolled alloca() by writing a crafted message to /run/systemd/journal/socket that results in a stack buffer overflow. This can lead to a denial of service attack or arbitrary code execution in some cases.
A flaw was found in systemd-journald. A stack buffer overflow when passing several MB of arguments to a program calling syslog function. This can lead to a denial of service attack or arbitrary code execution in some cases.
A race condition in chownone() of systemd allows an attacker to cause systemd to set arbitrary permissions on arbitrary files. Affected releases are systemd versions up to and including 239.
systemd is vulnerable to line splitting via long lines read by fgets() in the unitdeserialize() function during daemon-reexec (e.g. during a package upgrade) allowing for state injection. Systemd services with NotifyAccess != none and malicious executables can exploit this vulnerability resulting corrupted process state.
A vulnerability in unitdeserialize of systemd allows an attacker to supply arbitrary state across systemd re-execution via NotifyAccess. This can be used to improperly influence systemd execution and possibly lead to root privilege escalation. Affected releases are systemd versions up to and including 239.
A buffer overflow vulnerability in the dhcp6 client of systemd allows a malicious dhcp6 server to overwrite heap memory in systemd-networkd. Affected releases are systemd: versions up to and including 239.
systemd-tmpfiles in systemd before 237 attempts to support ownership/permission changes on hardlinked files even if the fs.protectedhardlinks 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 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.
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.
It was found that systemd fails an assertion in managerinvokenotifymessage() when a zero-length message is received over its notification socket, causing it to no longer perform it's expected functionality. This issue was assigned CVE-2016-7795 and is tracked via bug 1380286. Upstream bug report is:
https://github.com/systemd/systemd/issues/4234
Older systemd versions either don't include the assert that is triggered in managerinvokenotifymessage(), or have managerprocessnotifyfd() function return error before calling managerinvokenotifymessage(). That error return still causes systemd to exit its main loop and freeze its execution in a similar way it's done in newer versions after failed assertion.
https://github.com/systemd/systemd/issues/4234#issuecomment-250441246
The managerinvokenotifymessage() function with assert was introduced in version v209:
https://github.com/systemd/systemd/commit/5ba6985b6c8ef85a8bcfeb1b65239c863436e75b#diff-ab78220e12703ee63fa1e6a2caa16bebR1319
However, the assertion was not reachable before the error return was removed in v219:
https://github.com/systemd/systemd/commit/d875aa8ce10b458dc218c0d98f4a82c8904d6d03
The systemd versions in Red Hat Enterprise Linux 7.0 and 7.1 are based on upstream v208, but include managerinvokenotifymessage() added via a separate backported patch. The assertion is not reachable, so those versions are affected by CVE-2016-7796, but not affected by CVE-2016-7795. Red Hat Enterprise Linux 7.2 rebased systemd to version v219. Therefore, those packages are no longer affected by CVE-2016-7796, but are now affected by CVE-2016-7795.
It was found that systemd fails an assertion in managerinvokenotifymessage 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:
NOTIFYSOCKET=/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
A flaw was found in the way systemd handled empty notification messages. A local attacker could use this flaw to make systemd freeze its execution, preventing further management of system services, system shutdown, or zombie process collection via systemd.
A stack-based buffer overflow vulnerability was found in getpwnam()/getgrnam() functions of NSS module nss-mymachines provided by systemd.
Sebastian Krahmer reported a security issue was found in polkit (CVE-2013-4288 bz 1002375).
It was found that systemd was vulnerable to this issue as well, since it communicated to polkit authority using an unsafe DBUS interface.
This issue has been assigned CVE-2013-4327
Sebastian Krahmer reported a security issue was found in polkit (CVE-2013-4288 bz 1002375).
It was found that systemd was vulnerable to this issue as well, since it communicated to polkit authority using an unsafe DBUS interface.
This issue has been assigned CVE-2013-4327
A possibility of unauthorized Xorg X11 Server configuration file modification / injection was found in the way SetX11Keyboard() method of systemd, a system and service manager, performed sanitization of provided X Keyboard Extension (XKB) layouts description (special and control characters were not filtered out from the layout description properly). When the host in question used PolicyKit Local Authority (PKLA) file mechanism to grant group of users the privilege to change XKB settings (instead of default PolicyKit check) and particular local attacker was member of that group, they could use this flaw to inject arbitrary values into the Xorg X11 Server configuration file, possibly leading to escalation of their privileges.
Issue found by Florian Weimer, Red Hat Product Security Team
A possibility of unauthorized Xorg X11 Server configuration file modification / injection was found in the way SetX11Keyboard() method of systemd, a system and service manager, performed sanitization of provided X Keyboard Extension (XKB) layouts description (special and control characters were not filtered out from the layout description properly). When the host in question used PolicyKit Local Authority (PKLA) file mechanism to grant group of users the privilege to change XKB settings (instead of default PolicyKit check) and particular local attacker was member of that group, they could use this flaw to inject arbitrary values into the Xorg X11 Server configuration file, possibly leading to escalation of their privileges.
Issue found by Florian Weimer, Red Hat Product Security Team