vulnerability
Ubuntu: (CVE-2025-38017): linux-gcp-6.14 vulnerability
| Severity | CVSS | Published | Added | Modified |
|---|---|---|---|---|
| 5 | (AV:L/AC:L/Au:S/C:N/I:N/A:C) | Jun 18, 2025 | Sep 26, 2025 | Nov 19, 2025 |
Description
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].
Solutions
References
- CVE-2025-38017
- https://attackerkb.com/topics/CVE-2025-38017
- URL-https://git.kernel.org/linus/d9ec73301099ec5975505e1c3effbe768bab9490
- URL-https://git.kernel.org/stable/c/7631dca012593c95d36199082546a24a0058fc50
- URL-https://git.kernel.org/stable/c/d9ec73301099ec5975505e1c3effbe768bab9490
- URL-https://www.cve.org/CVERecord?id=CVE-2025-38017
Explore Exposure Command
Confidently identify and prioritize exposures from endpoint to cloud with full attack surface visibility and threat-aware risk context.