https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Thu, 01 Oct 2026 13:53:24 +0000 https://vulnerability.circl.lu/vuln/cve-2025-38017 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>fs/eventpoll: fix endless busy loop after timeout has expired</p> <p>After commit 0a65bc27bd64 (&#34;eventpoll: Set epoll timeout if it&#39;s in the future&#34;), the following program would immediately enter a busy loop in the kernel:</p> <p>``` int main() { int e = epoll_create1(0); struct epoll_event event = {.events = EPOLLIN}; epoll_ctl(e, EPOLL_CTL_ADD, 0, &amp;event); const struct timespec timeout = {.tv_nsec = 1}; epoll_pwait2(e, &amp;event, 1, &amp;timeout, 0); } ```</p> <p>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.</p> <p>When the timeout has expired, we don&#39;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.</p> <p>brauner: Note that there was an earlier fix by Joe Damato in response to my bug report in [1].</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>fs/eventpoll: fix endless busy loop after timeout has expired</p> <p>After commit 0a65bc27bd64 (&#34;eventpoll: Set epoll timeout if it&#39;s in the future&#34;), the following program would immediately enter a busy loop in the kernel:</p> <p>``` int main() { int e = epoll_create1(0); struct epoll_event event = {.events = EPOLLIN}; epoll_ctl(e, EPOLL_CTL_ADD, 0, &amp;event); const struct timespec timeout = {.tv_nsec = 1}; epoll_pwait2(e, &amp;event, 1, &amp;timeout, 0); } ```</p> <p>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.</p> <p>When the timeout has expired, we don&#39;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.</p> <p>brauner: Note that there was an earlier fix by Joe Damato in response to my bug report in [1].</p> https://vulnerability.circl.lu/vuln/cve-2025-38017