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
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
A possibility for denial of loggin service was found in the way journald functionality of systemd, a system and service manager, processed native messages when file was chosen as their origin. A local attacker could use this flaw to provide a specially-crafted file descriptor, leading the journald file read process to block, resultingin portion of subsequent native messages intended to be logged to be ignored.
Issue found by Florian Weimer, Red Hat Product Security Team
A possibility for denial of loggin service was found in the way journald functionality of systemd, a system and service manager, processed native messages when file was chosen as their origin. A local attacker could use this flaw to provide a specially-crafted file descriptor, leading the journald file read process to block, resultingin portion of subsequent native messages intended to be logged to be ignored.
Issue found by Florian Weimer, Red Hat Product Security Team
A TOCTOU (time-of-check time-of-use) race condition was found in the way systemd, a system and service manager, used to update file permissions and SELinux security contexts. A local attacker could use this flaw to conduct symbolic link attacks possibly leading to their ability to modify permissions / security context of a path different than originally intended / requested.
Issue found by Florian Weimer, Red Hat Product Security Team