fkie_cve-2025-38017
Vulnerability from fkie_nvd
Published
2025-06-18 10:15
Modified
2025-06-18 13:46
Severity ?
Summary
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].
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/7631dca012593c95d36199082546a24a0058fc50
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/d9ec73301099ec5975505e1c3effbe768bab9490
Impacted products
Vendor Product Version


To clipboard 

{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs/eventpoll: fix endless busy loop after timeout has expired\n\nAfter commit 0a65bc27bd64 (\"eventpoll: Set epoll timeout if it\u0027s in\nthe future\"), the following program would immediately enter a busy\nloop in the kernel:\n\n```\nint main() {\n  int e = epoll_create1(0);\n  struct epoll_event event = {.events = EPOLLIN};\n  epoll_ctl(e, EPOLL_CTL_ADD, 0, \u0026event);\n  const struct timespec timeout = {.tv_nsec = 1};\n  epoll_pwait2(e, \u0026event, 1, \u0026timeout, 0);\n}\n```\n\nThis happens because the given (non-zero) timeout of 1 nanosecond\nusually expires before ep_poll() is entered and then\nep_schedule_timeout() returns false, but `timed_out` is never set\nbecause the code line that sets it is skipped.  This quickly turns\ninto a soft lockup, RCU stalls and deadlocks, inflicting severe\nheadaches to the whole system.\n\nWhen the timeout has expired, we don\u0027t need to schedule a hrtimer, but\nwe should set the `timed_out` variable.  Therefore, I suggest moving\nthe ep_schedule_timeout() check into the `timed_out` expression\ninstead of skipping it.\n\nbrauner: Note that there was an earlier fix by Joe Damato in response to\nmy bug report in [1]."
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/eventpoll: corrige un bucle ocupado sin fin despu\u00e9s de que expira el tiempo de espera Despu\u00e9s de el commit 0a65bc27bd64 (\"eventpoll: establece el tiempo de espera de epoll si es en el futuro\"), el siguiente programa ingresar\u00eda inmediatamente en un bucle ocupado en el kernel: ``` int main() { int e = epoll_create1(0); struct epoll_event event = {.events = EPOLLIN}; epoll_ctl(e, EPOLL_CTL_ADD, 0, \u0026amp;event); const struct timespec timeout = {.tv_nsec = 1}; epoll_pwait2(e, \u0026amp;event, 1, \u0026amp;timeout, 0); } ``` Esto sucede porque el tiempo de espera dado (distinto de cero) de 1 nanosegundo generalmente expira antes de que se ingrese ep_poll() y luego ep_schedule_timeout() devuelve falso, pero `timed_out` nunca se establece porque se omite la l\u00ednea de c\u00f3digo que lo establece. Esto r\u00e1pidamente se convierte en un bloqueo suave, RCU se bloquea y se bloquea, lo que inflige graves dolores de cabeza a todo el sistema. Cuando el tiempo de espera ha expirado, no necesitamos programar un hrtimer, pero debemos establecer la variable `timed_out`. Por lo tanto, sugiero mover la comprobaci\u00f3n de ep_schedule_timeout() a la expresi\u00f3n `timed_out` en lugar de omitirla. brauner: Tenga en cuenta que hubo una correcci\u00f3n anterior por Joe Damato en respuesta a mi informe de error en [1]."
    }
  ],
  "id": "CVE-2025-38017",
  "lastModified": "2025-06-18T13:46:52.973",
  "metrics": {},
  "published": "2025-06-18T10:15:33.310",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/7631dca012593c95d36199082546a24a0058fc50"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/d9ec73301099ec5975505e1c3effbe768bab9490"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.