fkie_cve-2025-38614
Vulnerability from fkie_nvd
Published
2025-08-19 17:15
Modified
2025-11-03 18:16
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved:
eventpoll: Fix semi-unbounded recursion
Ensure that epoll instances can never form a graph deeper than
EP_MAX_NESTS+1 links.
Currently, ep_loop_check_proc() ensures that the graph is loop-free and
does some recursion depth checks, but those recursion depth checks don't
limit the depth of the resulting tree for two reasons:
- They don't look upwards in the tree.
- If there are multiple downwards paths of different lengths, only one of
the paths is actually considered for the depth check since commit
28d82dc1c4ed ("epoll: limit paths").
Essentially, the current recursion depth check in ep_loop_check_proc() just
serves to prevent it from recursing too deeply while checking for loops.
A more thorough check is done in reverse_path_check() after the new graph
edge has already been created; this checks, among other things, that no
paths going upwards from any non-epoll file with a length of more than 5
edges exist. However, this check does not apply to non-epoll files.
As a result, it is possible to recurse to a depth of at least roughly 500,
tested on v6.15. (I am unsure if deeper recursion is possible; and this may
have changed with commit 8c44dac8add7 ("eventpoll: Fix priority inversion
problem").)
To fix it:
1. In ep_loop_check_proc(), note the subtree depth of each visited node,
and use subtree depths for the total depth calculation even when a subtree
has already been visited.
2. Add ep_get_upwards_depth_proc() for similarly determining the maximum
depth of an upwards walk.
3. In ep_loop_check(), use these values to limit the total path length
between epoll nodes to EP_MAX_NESTS edges.
References
Impacted products
| Vendor | Product | Version |
|---|
{
"cveTags": [],
"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\u0027t\nlimit the depth of the resulting tree for two reasons:\n\n - They don\u0027t 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. "
}
],
"id": "CVE-2025-38614",
"lastModified": "2025-11-03T18:16:31.723",
"metrics": {},
"published": "2025-08-19T17:15:40.040",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/1b13b033062824495554e836a1ff5f85ccf6b039"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/2a0c0c974bea9619c6f41794775ae4b97530e0e6"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/3542c90797bc3ab83ebab54b737d751cf3682036"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/71379495ab70eaba19224bd71b5b9b399eb85e04"
},
{
"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": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Awaiting Analysis"
}
Loading…
Loading…
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.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- 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.
Loading…
Loading…