CVE-2025-38017 (GCVE-0-2025-38017)
Vulnerability from cvelistv5
Published
2025-06-18 09:28
Modified
2025-06-18 09:28
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
Impacted products
Vendor Product Version
Linux Linux Version: 99a0ad16dfd114a429df665065dcc576dad743c0
Version: 0a65bc27bd645894175c059397b4916e31955fb2
 Create a notification for this product.
Show details on NVD website

To clipboard 

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "fs/eventpoll.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "7631dca012593c95d36199082546a24a0058fc50",
              "status": "affected",
              "version": "99a0ad16dfd114a429df665065dcc576dad743c0",
              "versionType": "git"
            },
            {
              "lessThan": "d9ec73301099ec5975505e1c3effbe768bab9490",
              "status": "affected",
              "version": "0a65bc27bd645894175c059397b4916e31955fb2",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "fs/eventpoll.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "6.14.8",
              "status": "affected",
              "version": "6.14.4",
              "versionType": "semver"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.14.8",
                  "versionStartIncluding": "6.14.4",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "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]."
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2025-06-18T09:28:25.790Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/7631dca012593c95d36199082546a24a0058fc50"
        },
        {
          "url": "https://git.kernel.org/stable/c/d9ec73301099ec5975505e1c3effbe768bab9490"
        }
      ],
      "title": "fs/eventpoll: fix endless busy loop after timeout has expired",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2025-38017",
    "datePublished": "2025-06-18T09:28:25.790Z",
    "dateReserved": "2025-04-16T04:51:23.977Z",
    "dateUpdated": "2025-06-18T09:28:25.790Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2025-38017\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-06-18T10:15:33.310\",\"lastModified\":\"2025-06-18T13:46:52.973\",\"vulnStatus\":\"Awaiting Analysis\",\"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].\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/7631dca012593c95d36199082546a24a0058fc50\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/d9ec73301099ec5975505e1c3effbe768bab9490\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}"
  }
}


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.