FKIE_CVE-2026-23159

Vulnerability from fkie_nvd - Published: 2026-02-14 16:15 - Updated: 2026-02-18 17:52
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: perf: sched: Fix perf crash with new is_user_task() helper In order to do a user space stacktrace the current task needs to be a user task that has executed in user space. It use to be possible to test if a task is a user task or not by simply checking the task_struct mm field. If it was non NULL, it was a user task and if not it was a kernel task. But things have changed over time, and some kernel tasks now have their own mm field. An idea was made to instead test PF_KTHREAD and two functions were used to wrap this check in case it became more complex to test if a task was a user task or not[1]. But this was rejected and the C code simply checked the PF_KTHREAD directly. It was later found that not all kernel threads set PF_KTHREAD. The io-uring helpers instead set PF_USER_WORKER and this needed to be added as well. But checking the flags is still not enough. There's a very small window when a task exits that it frees its mm field and it is set back to NULL. If perf were to trigger at this moment, the flags test would say its a user space task but when perf would read the mm field it would crash with at NULL pointer dereference. Now there are flags that can be used to test if a task is exiting, but they are set in areas that perf may still want to profile the user space task (to see where it exited). The only real test is to check both the flags and the mm field. Instead of making this modification in every location, create a new is_user_task() helper function that does all the tests needed to know if it is safe to read the user space memory or not. [1] https://lore.kernel.org/all/20250425204120.639530125@goodmis.org/
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/5aac392fcd3d981d7997f1a0766829e1afdeac2e
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/76ed27608f7dd235b727ebbb12163438c2fbb617
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/a28fce0365e1cb9cb8c04c893b9334e5ca9d9f1c
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/d84a4836dc246b7dc244e46a08ff992956b68db0
Impacted products
Vendor Product Version
To clipboard 

{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nperf: sched: Fix perf crash with new is_user_task() helper\n\nIn order to do a user space stacktrace the current task needs to be a user\ntask that has executed in user space. It use to be possible to test if a\ntask is a user task or not by simply checking the task_struct mm field. If\nit was non NULL, it was a user task and if not it was a kernel task.\n\nBut things have changed over time, and some kernel tasks now have their\nown mm field.\n\nAn idea was made to instead test PF_KTHREAD and two functions were used to\nwrap this check in case it became more complex to test if a task was a\nuser task or not[1]. But this was rejected and the C code simply checked\nthe PF_KTHREAD directly.\n\nIt was later found that not all kernel threads set PF_KTHREAD. The io-uring\nhelpers instead set PF_USER_WORKER and this needed to be added as well.\n\nBut checking the flags is still not enough. There\u0027s a very small window\nwhen a task exits that it frees its mm field and it is set back to NULL.\nIf perf were to trigger at this moment, the flags test would say its a\nuser space task but when perf would read the mm field it would crash with\nat NULL pointer dereference.\n\nNow there are flags that can be used to test if a task is exiting, but\nthey are set in areas that perf may still want to profile the user space\ntask (to see where it exited). The only real test is to check both the\nflags and the mm field.\n\nInstead of making this modification in every location, create a new\nis_user_task() helper function that does all the tests needed to know if\nit is safe to read the user space memory or not.\n\n[1] https://lore.kernel.org/all/20250425204120.639530125@goodmis.org/"
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:\n\nperf: sched: Soluciona el fallo de perf con la nueva funci\u00f3n auxiliar is_user_task()\n\nPara realizar un seguimiento de pila (stacktrace) del espacio de usuario, la tarea actual debe ser una tarea de usuario que se haya ejecutado en el espacio de usuario. Sol\u00eda ser posible comprobar si una tarea es una tarea de usuario o no simplemente verificando el campo mm de task_struct. Si no era NULL, era una tarea de usuario y si no, era una tarea del kernel.\n\nPero las cosas han cambiado con el tiempo, y algunas tareas del kernel ahora tienen su propio campo mm.\n\nSe propuso la idea de probar PF_KTHREAD en su lugar y se utilizaron dos funciones para encapsular esta verificaci\u00f3n en caso de que se volviera m\u00e1s complejo probar si una tarea era una tarea de usuario o no[1]. Pero esto fue rechazado y el c\u00f3digo C simplemente verific\u00f3 PF_KTHREAD directamente.\n\nM\u00e1s tarde se descubri\u00f3 que no todos los hilos del kernel establecen PF_KTHREAD. Los auxiliares de io-uring, en cambio, establecen PF_USER_WORKER y esto tambi\u00e9n necesitaba ser a\u00f1adido.\n\nPero verificar las banderas (flags) todav\u00eda no es suficiente. Hay una ventana muy peque\u00f1a cuando una tarea sale en la que libera su campo mm y este se vuelve a establecer en NULL. Si perf se activara en este momento, la prueba de las banderas dir\u00eda que es una tarea del espacio de usuario, pero cuando perf leyera el campo mm, fallar\u00eda con una desreferencia de puntero NULL.\n\nAhora hay banderas que se pueden usar para probar si una tarea est\u00e1 saliendo, pero se establecen en \u00e1reas que perf a\u00fan podr\u00eda querer perfilar en la tarea del espacio de usuario (para ver d\u00f3nde sali\u00f3). La \u00fanica prueba real es verificar tanto las banderas como el campo mm.\n\nEn lugar de realizar esta modificaci\u00f3n en cada ubicaci\u00f3n, cree una nueva funci\u00f3n auxiliar is_user_task() que realice todas las pruebas necesarias para saber si es seguro leer la memoria del espacio de usuario o no.\n\n[1] https://lore.kernel.org/all/20250425204120.639530125@goodmis.org/"
    }
  ],
  "id": "CVE-2026-23159",
  "lastModified": "2026-02-18T17:52:44.520",
  "metrics": {},
  "published": "2026-02-14T16:15:56.070",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/5aac392fcd3d981d7997f1a0766829e1afdeac2e"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/76ed27608f7dd235b727ebbb12163438c2fbb617"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/a28fce0365e1cb9cb8c04c893b9334e5ca9d9f1c"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/d84a4836dc246b7dc244e46a08ff992956b68db0"
    }
  ],
  "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 observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Detection rules are retrieved from Rulezet.