CVE-2025-38017 in Linux
Summary
by MITRE • 06/18/2025
In the Linux kernel, the following vulnerability has been resolved:
fs/eventpoll: fix endless busy loop after timeout has expired
After commit 0a65bc27bd64 ("eventpoll: Set epoll timeout if it's in the future"), the following program would immediately enter a busy loop in the kernel:
``` int main() {
int e = epoll_create1(0); struct epoll_event event = {.events = EPOLLIN};
epoll_ctl(e, EPOLL_CTL_ADD, 0, &event); const struct timespec timeout = {.tv_nsec = 1};
epoll_pwait2(e, &event, 1, &timeout, 0); } ```
This happens because the given (non-zero) timeout of 1 nanosecond usually expires before ep_poll() is entered and then ep_schedule_timeout() returns false, but `timed_out` is never set because the code line that sets it is skipped. This quickly turns into a soft lockup, RCU stalls and deadlocks, inflicting severe headaches to the whole system.
When the timeout has expired, we don't need to schedule a hrtimer, but we should set the `timed_out` variable. Therefore, I suggest moving the ep_schedule_timeout() check into the `timed_out` expression instead of skipping it.
brauner: Note that there was an earlier fix by Joe Damato in response to my bug report in [1].
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 02/02/2026
The vulnerability described in CVE-2025-38017 represents a critical race condition within the Linux kernel's eventpoll subsystem that can lead to system instability and potential denial of service conditions. This flaw specifically affects the epoll_wait and epoll_pwait2 system calls which are fundamental components for efficient I/O multiplexing in Linux applications. The issue manifests when a process attempts to monitor file descriptors using epoll with a very short timeout value, typically in the nanosecond range, causing the kernel to enter an infinite busy loop that consumes excessive CPU resources and can result in system lockups.
The technical root cause of this vulnerability stems from improper handling of timeout conditions within the eventpoll implementation. When a timeout value of 1 nanosecond is specified in the epoll_pwait2 call, the kernel's timing logic fails to properly set the timed_out flag even when the timeout has already expired. This occurs due to a flawed conditional check in the ep_schedule_timeout() function where the code path that sets the timed_out variable is bypassed, leaving the system in an inconsistent state. The vulnerability is classified under CWE-362 as a race condition that can lead to improper handling of concurrent operations, specifically involving timing and state management within kernel space.
The operational impact of this vulnerability extends beyond simple performance degradation to potentially catastrophic system failures including soft lockups, RCU (Read-Copy-Update) stalls, and various deadlock conditions that can render the entire system unresponsive. The infinite busy loop consumes CPU cycles continuously without yielding control back to the scheduler, effectively preventing other processes from executing normally and creating a denial of service scenario. This vulnerability affects systems running Linux kernels that include the specific commit referenced in the patch, making it particularly dangerous for server environments and applications that rely heavily on epoll for managing multiple concurrent connections or I/O operations.
The fix implemented addresses this issue by reorganizing the timeout handling logic to ensure that the timed_out variable is properly set when timeouts have expired, regardless of whether a high-resolution timer needs to be scheduled. This change aligns with the ATT&CK framework's concept of privilege escalation through kernel exploitation by preventing malicious or accidental misuse of system calls from causing system-wide instability. The solution moves the ep_schedule_timeout() check into the timed_out expression, ensuring proper state management and preventing the infinite loop that would otherwise occur. This remediation technique demonstrates proper kernel programming practices for handling timing conditions and state transitions, emphasizing the importance of comprehensive error handling and race condition prevention in kernel-level code that directly impacts system stability and security.