Entreprise française de cybersécurité depuis 2004
☎ 03 60 47 09 81 - info@securiteinfo.com
☎ 03 60 47 09 81 - info@securiteinfo.com
In the Linux kernel, the following vulnerability has been resolved:eventpoll: Fix semi-unbounded recursionEnsure that epoll instances can never form a graph deeper thanEP_MAX_NESTS+1 links.Currently, ep_loop_check_proc() ensures that the graph is loop-free anddoes some recursion depth checks, but those recursion depth checks don'tlimit 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() justserves to prevent it from recursing too deeply while checking for loops.A more thorough check is done in reverse_path_check() after the new graphedge has already been created; this checks, among other things, that nopaths going upwards from any non-epoll file with a length of more than 5edges 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 mayhave changed with commit 8c44dac8add7 ("eventpoll: Fix priority inversionproblem").)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 subtreehas already been visited.2. Add ep_get_upwards_depth_proc() for similarly determining the maximumdepth of an upwards walk.3. In ep_loop_check(), use these values to limit the total path lengthbetween epoll nodes to EP_MAX_NESTS edges.
No PoCs from references.
- https://github.com/fkie-cad/nvd-json-data-feeds
- https://github.com/w4zu/Debian_security