Linux Kernel up to 6.14.7 eventpoll main timed_out deadlock

Summaryinfo

A vulnerability was found in Linux Kernel up to 6.14.7. It has been rated as critical. Affected by this vulnerability is the function main of the component eventpoll. The manipulation of the argument timed_out leads to deadlock. This vulnerability is documented as CVE-2025-38017. There is not any exploit available. Upgrading the affected component is advised.

Detailsinfo

A vulnerability, which was classified as critical, has been found in Linux Kernel up to 6.14.7. This issue affects the function main of the component eventpoll. The manipulation of the argument timed_out with an unknown input leads to a deadlock vulnerability. Using CWE to declare the problem leads to CWE-833. The product contains multiple threads or executable segments that are waiting for each other to release a necessary lock, resulting in deadlock. Impacted is availability. The summary by CVE is:

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].

It is possible to read the advisory at git.kernel.org. The identification of this vulnerability is CVE-2025-38017 since 04/16/2025. The exploitation is known to be difficult. Technical details of the vulnerability are known, but there is no available exploit.

Upgrading to version 6.14.8 eliminates this vulnerability. Applying the patch 7631dca012593c95d36199082546a24a0058fc50/d9ec73301099ec5975505e1c3effbe768bab9490 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.

The vulnerability is also documented in the vulnerability database at CERT Bund (WID-SEC-2025-1350). Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Affected

• Debian Linux
• Amazon Linux 2
• Red Hat Enterprise Linux
• Ubuntu Linux
• SUSE Linux
• Oracle Linux
• SUSE openSUSE
• Open Source Linux Kernel
• RESF Rocky Linux
• Dell Avamar
• Dell NetWorker
• Dell Secure Connect Gateway
• IBM QRadar SIEM

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 6.14.0
• 6.14.1
• 6.14.2
• 6.14.3
• 6.14.4
• 6.14.5
• 6.14.6
• 6.14.7

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔍
• 🔍
• 🔍

CPE 2.2info

• 🔍
• 🔍
• 🔍

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Discussion