CVE-2025-38614

{"id": "CVE-2025-38614", "cveTags": [], "metrics": {}, "published": "2025-08-19T17:15:40.040", "references": [{"url": "https://git.kernel.org/stable/c/3542c90797bc3ab83ebab54b737d751cf3682036", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/7a2125962c42d5336ca0495a9ce4cb38a63e9161", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/ea5f97dbdcb1651581a22bd10afd2f0dd9dc11d6", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/f2e467a48287c868818085aa35389a224d226732", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}], "vulnStatus": "Awaiting Analysis", "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\neventpoll: Fix semi-unbounded recursion\n\nEnsure that epoll instances can never form a graph deeper than\nEP_MAX_NESTS+1 links.\n\nCurrently, ep_loop_check_proc() ensures that the graph is loop-free and\ndoes some recursion depth checks, but those recursion depth checks don't\nlimit the depth of the resulting tree for two reasons:\n\n - They don't look upwards in the tree.\n - If there are multiple downwards paths of different lengths, only one of\n the paths is actually considered for the depth check since commit\n 28d82dc1c4ed (\"epoll: limit paths\").\n\nEssentially, the current recursion depth check in ep_loop_check_proc() just\nserves to prevent it from recursing too deeply while checking for loops.\n\nA more thorough check is done in reverse_path_check() after the new graph\nedge has already been created; this checks, among other things, that no\npaths going upwards from any non-epoll file with a length of more than 5\nedges exist. However, this check does not apply to non-epoll files.\n\nAs a result, it is possible to recurse to a depth of at least roughly 500,\ntested on v6.15. (I am unsure if deeper recursion is possible; and this may\nhave changed with commit 8c44dac8add7 (\"eventpoll: Fix priority inversion\nproblem\").)\n\nTo fix it:\n\n1. In ep_loop_check_proc(), note the subtree depth of each visited node,\nand use subtree depths for the total depth calculation even when a subtree\nhas already been visited.\n2. Add ep_get_upwards_depth_proc() for similarly determining the maximum\ndepth of an upwards walk.\n3. In ep_loop_check(), use these values to limit the total path length\nbetween epoll nodes to EP_MAX_NESTS edges."}, {"lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: eventpoll: Arregla recursi\u00f3n semi-ilimitada Garantiza que las instancias de epoll nunca puedan formar un grafo m\u00e1s profundo que los enlaces EP_MAX_NESTS+1. Actualmente, ep_loop_check_proc() garantiza que el grafo no tenga bucles y realiza algunas comprobaciones de profundidad de recursi\u00f3n, pero esas comprobaciones de profundidad de recursi\u00f3n no limitan la profundidad del \u00e1rbol resultante por dos razones: - No miran hacia arriba en el \u00e1rbol. - Si hay m\u00faltiples rutas descendentes de diferentes longitudes, solo una de las rutas se considera realmente para la comprobaci\u00f3n de profundidad desde el commit 28d82dc1c4ed (\"epoll: limitar rutas\"). Esencialmente, la comprobaci\u00f3n de profundidad de recursi\u00f3n actual en ep_loop_check_proc() solo sirve para evitar que recurra demasiado profundamente mientras comprueba bucles. Se realiza una comprobaci\u00f3n m\u00e1s exhaustiva en reverse_path_check() despu\u00e9s de que ya se haya creado el nuevo borde del grafo; Esto comprueba, entre otras cosas, que no existan rutas ascendentes desde ning\u00fan archivo que no sea epoll con una longitud de m\u00e1s de 5 aristas. Sin embargo, esta comprobaci\u00f3n no se aplica a los archivos que no son epoll. Como resultado, es posible realizar una recursi\u00f3n a una profundidad de al menos aproximadamente 500, probada en la versi\u00f3n v6.15. (No estoy seguro de si es posible una recursi\u00f3n m\u00e1s profunda; esto puede haber cambiado con el commit 8c44dac8add7 (\"eventpoll: Correcci\u00f3n del problema de inversi\u00f3n de prioridad\")). Para solucionarlo: 1. En ep_loop_check_proc(), anote la profundidad del sub\u00e1rbol de cada nodo visitado y utilice las profundidades del sub\u00e1rbol para el c\u00e1lculo de la profundidad total, incluso si ya se ha visitado un sub\u00e1rbol. 2. A\u00f1ada ep_get_upwards_depth_proc() para determinar de forma similar la profundidad m\u00e1xima de un recorrido ascendente. 3. En ep_loop_check(), utilice estos valores para limitar la longitud total de la ruta entre nodos epoll a EP_MAX_NESTS aristas. "}], "lastModified": "2025-08-20T18:15:31.897", "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}