CVE-2025-38017

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/eventpoll: fix endless busy loop after timeout has expired<br /> <br /> After commit 0a65bc27bd64 ("eventpoll: Set epoll timeout if it&amp;#39;s in<br /> the future"), the following program would immediately enter a busy<br /> loop in the kernel:<br /> <br /> ```<br /> int main() {<br /> int e = epoll_create1(0);<br /> struct epoll_event event = {.events = EPOLLIN};<br /> epoll_ctl(e, EPOLL_CTL_ADD, 0, &amp;event);<br /> const struct timespec timeout = {.tv_nsec = 1};<br /> epoll_pwait2(e, &amp;event, 1, &amp;timeout, 0);<br /> }<br /> ```<br /> <br /> This happens because the given (non-zero) timeout of 1 nanosecond<br /> usually expires before ep_poll() is entered and then<br /> ep_schedule_timeout() returns false, but `timed_out` is never set<br /> because the code line that sets it is skipped. This quickly turns<br /> into a soft lockup, RCU stalls and deadlocks, inflicting severe<br /> headaches to the whole system.<br /> <br /> When the timeout has expired, we don&amp;#39;t need to schedule a hrtimer, but<br /> we should set the `timed_out` variable. Therefore, I suggest moving<br /> the ep_schedule_timeout() check into the `timed_out` expression<br /> instead of skipping it.<br /> <br /> brauner: Note that there was an earlier fix by Joe Damato in response to<br /> my bug report in [1].