linux-cve-announce - CVE-2025-38614: eventpoll: Fix semi-unbounded recursion

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <2025081924-CVE-2025-38614-883c@gregkh>
Date: Tue, 19 Aug 2025 19:19:00 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...nel.org>
Subject: CVE-2025-38614: eventpoll: Fix semi-unbounded recursion

From: Greg Kroah-Hartman <gregkh@...nel.org>

Description
===========

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.

The Linux kernel CVE team has assigned CVE-2025-38614 to this issue.

Affected and fixed versions
===========================

	Issue introduced in 2.6.38 with commit 22bacca48a1755f79b7e0f192ddb9fbb7fc6e64e and fixed in 6.16.1 with commit 3542c90797bc3ab83ebab54b737d751cf3682036
	Issue introduced in 2.6.38 with commit 22bacca48a1755f79b7e0f192ddb9fbb7fc6e64e and fixed in 6.17-rc1 with commit f2e467a48287c868818085aa35389a224d226732
	Issue introduced in 2.6.32.30 with commit 8216e1a0d47cae06a75c42346f19dffe14e42d57
	Issue introduced in 2.6.33.8 with commit 28a92748aa4bc57d35e7b079498b0ac2e7610a37
	Issue introduced in 2.6.34.10 with commit 7eebcd4792c5a341559aed327b6afecbb1c46402
	Issue introduced in 2.6.35.12 with commit 0eccd188cfeaf857a26f2d72941d27d298cf6a54
	Issue introduced in 2.6.37.3 with commit a72affdbb09f3f24f64ffcbbdf62c2e57c58f379

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2025-38614
will be updated if fixes are backported, please check that for the most
up to date information about this issue.

Affected files
==============

The file(s) affected by this issue are:
	fs/eventpoll.c

Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/3542c90797bc3ab83ebab54b737d751cf3682036
	https://git.kernel.org/stable/c/f2e467a48287c868818085aa35389a224d226732