CVE-2026-80663 in Linuxinfo

Summary

by MITRE • 08/28/2026

In the Linux kernel, the following vulnerability has been resolved:

tools/power/x86/intel-speed-select: Harden daemon pidfile open

Avoid symlink-based pidfile clobbering by opening the pidfile with O_NOFOLLOW and validating it with fstat() before locking/writing.

The daemon currently uses a fixed pidfile path under /tmp. A local unprivileged user can pre-create a symlink at that path and cause a root-run daemon instance to write into an attacker-chosen file.

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Analysis

by VulDB Data Team • 08/28/2026

The Linux kernel utility intel-speed-select contains a privilege escalation vulnerability within its power management daemon, specifically related to the handling of process identification files. This flaw stems from insecure temporary file creation practices where the application relies on a fixed path located in the /tmp directory without implementing sufficient safeguards against race conditions or symbolic link attacks. The core technical deficiency lies in the method used to open and write to the pidfile. Instead of using atomic operations that guarantee exclusive access, the daemon opens the file for writing based solely on its pathname. This approach fails to verify whether the path resolves to a regular file or if it has been manipulated by another process prior to the actual write operation.

A local unprivileged user can exploit this vulnerability through a symlink-based attack vector. By pre-creating a symbolic link at the expected pidfile location within /tmp, an attacker can redirect any subsequent writes intended for the daemon's status tracking into arbitrary files on the system. When the root-run instance of intel-speed-select starts or updates its state, it follows the symbolic link and overwrites the target file with new content. This behavior effectively allows a low-privilege user to write data as if they were the superuser, bypassing standard filesystem permission checks because the kernel permits following symlinks during open operations unless explicitly restricted.

The operational impact of this vulnerability is significant in multi-user environments or systems where untrusted users have access to temporary directories. An attacker can overwrite critical system configuration files, log files, or other sensitive data located outside of /tmp by crafting a symlink that points to those targets. This capability facilitates arbitrary file write attacks which can lead further into privilege escalation if the overwritten content is interpreted as executable code or configuration directives by higher-privilege services. Additionally, this flaw undermines the integrity of the daemon's own state management, potentially causing denial of service conditions for power management features on affected systems.

This vulnerability aligns with CWE-59 Improper Link Resolution Before File Access and CWE-377 Insecure Temporary File Creation within the Common Weakness Enumeration framework. From a threat modeling perspective, it corresponds to ATT&CK technique T1068 Exploitation for Privilege Escalation via symlink following attacks commonly seen in local privilege escalation scenarios. To mitigate this risk, developers must enforce strict file access controls when handling temporary files. The primary remediation involves opening the pidfile with the O_NOFOLLOW flag which prevents symbolic links from being followed during the open system call. Furthermore, after obtaining a file descriptor, the application should validate that the underlying inode corresponds to an expected regular file using fstat() before proceeding to lock or write data. Implementing these checks ensures that even if a symlink is present at the path location, the operation will fail safely rather than redirecting writes to unintended targets.

Responsible

Linux

Reservation

08/26/2026

Disclosure

08/28/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

very low

Sources

Might our Artificial Intelligence support you?

Check our Alexa App!