CVE-2025-38614

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> eventpoll: Fix semi-unbounded recursion<br /> <br /> Ensure that epoll instances can never form a graph deeper than<br /> EP_MAX_NESTS+1 links.<br /> <br /> Currently, ep_loop_check_proc() ensures that the graph is loop-free and<br /> does some recursion depth checks, but those recursion depth checks don&amp;#39;t<br /> limit the depth of the resulting tree for two reasons:<br /> <br /> - They don&amp;#39;t look upwards in the tree.<br /> - If there are multiple downwards paths of different lengths, only one of<br /> the paths is actually considered for the depth check since commit<br /> 28d82dc1c4ed ("epoll: limit paths").<br /> <br /> Essentially, the current recursion depth check in ep_loop_check_proc() just<br /> serves to prevent it from recursing too deeply while checking for loops.<br /> <br /> A more thorough check is done in reverse_path_check() after the new graph<br /> edge has already been created; this checks, among other things, that no<br /> paths going upwards from any non-epoll file with a length of more than 5<br /> edges exist. However, this check does not apply to non-epoll files.<br /> <br /> As a result, it is possible to recurse to a depth of at least roughly 500,<br /> tested on v6.15. (I am unsure if deeper recursion is possible; and this may<br /> have changed with commit 8c44dac8add7 ("eventpoll: Fix priority inversion<br /> problem").)<br /> <br /> To fix it:<br /> <br /> 1. In ep_loop_check_proc(), note the subtree depth of each visited node,<br /> and use subtree depths for the total depth calculation even when a subtree<br /> has already been visited.<br /> 2. Add ep_get_upwards_depth_proc() for similarly determining the maximum<br /> depth of an upwards walk.<br /> 3. In ep_loop_check(), use these values to limit the total path length<br /> between epoll nodes to EP_MAX_NESTS edges.