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.
Additional Descriptions (1)
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: eventpoll: Arregla recursión semi-ilimitada Garantiza que las instancias de epoll nunca puedan formar un grafo más 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ón, pero esas comprobaciones de profundidad de recursión no limitan la profundidad del árbol resultante por dos razones: - No miran hacia arriba en el árbol. - Si hay múltiples rutas descendentes de diferentes longitudes, solo una de las rutas se considera realmente para la comprobación de profundidad desde el commit 28d82dc1c4ed ("epoll: limitar rutas"). Esencialmente, la comprobación de profundidad de recursión actual en ep_loop_check_proc() solo sirve para evitar que recurra demasiado profundamente mientras comprueba bucles. Se realiza una comprobación más exhaustiva en reverse_path_check() después de que ya se haya creado el nuevo borde del grafo; Esto comprueba, entre otras cosas, que no existan rutas ascendentes desde ningún archivo que no sea epoll con una longitud de más de 5 aristas. Sin embargo, esta comprobación no se aplica a los archivos que no son epoll. Como resultado, es posible realizar una recursión a una profundidad de al menos aproximadamente 500, probada en la versión v6.15. (No estoy seguro de si es posible una recursión más profunda; esto puede haber cambiado con el commit 8c44dac8add7 ("eventpoll: Corrección del problema de inversión de prioridad")). Para solucionarlo: 1. En ep_loop_check_proc(), anote la profundidad del subárbol de cada nodo visitado y utilice las profundidades del subárbol para el cálculo de la profundidad total, incluso si ya se ha visitado un subárbol. 2. Añada ep_get_upwards_depth_proc() para determinar de forma similar la profundidad máxima 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.