CVE-2025-38614
eventpoll: Fix semi-unbounded recursion
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.
INFO
Published Date :
Aug. 19, 2025, 5:15 p.m.
Last Modified :
Jan. 9, 2026, 4:08 p.m.
Remotely Exploit :
No
Source :
416baaa9-dc9f-4396-8d5f-8c081fb06d67
CVSS Scores
| Score | Version | Severity | Vector | Exploitability Score | Impact Score | Source |
|---|---|---|---|---|---|---|
| CVSS 3.1 | MEDIUM | [email protected] |
Solution
- Apply the Linux kernel patch.
- Update to a patched kernel version.
- Configure epoll recursion depth limits.
- Review kernel event handling mechanisms.
References to Advisories, Solutions, and Tools
Here, you will find a curated list of external links that provide in-depth
information, practical solutions, and valuable tools related to
CVE-2025-38614.
CWE - Common Weakness Enumeration
While CVE identifies
specific instances of vulnerabilities, CWE categorizes the common flaws or
weaknesses that can lead to vulnerabilities. CVE-2025-38614 is
associated with the following CWEs:
Common Attack Pattern Enumeration and Classification (CAPEC)
Common Attack Pattern Enumeration and Classification
(CAPEC)
stores attack patterns, which are descriptions of the common attributes and
approaches employed by adversaries to exploit the CVE-2025-38614
weaknesses.
We scan GitHub repositories to detect new proof-of-concept exploits. Following list is a collection of public exploits and proof-of-concepts, which have been published on GitHub (sorted by the most recently updated).
Results are limited to the first 15 repositories due to potential performance issues.
The following list is the news that have been mention
CVE-2025-38614 vulnerability anywhere in the article.
The following table lists the changes that have been made to the
CVE-2025-38614 vulnerability over time.
Vulnerability history details can be useful for understanding the evolution of a vulnerability, and for identifying the most recent changes that may impact the vulnerability's severity, exploitability, or other characteristics.
-
Initial Analysis by [email protected]
Jan. 09, 2026
Action Type Old Value New Value Added CVSS V3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H Added CWE CWE-674 Added CPE Configuration OR *cpe:2.3:o:linux:linux_kernel:2.6.38:rc7:*:*:*:*:*:* *cpe:2.3:o:linux:linux_kernel:2.6.38:rc8:*:*:*:*:*:* *cpe:2.3:o:linux:linux_kernel:2.6.38:-:*:*:*:*:*:* *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.2 up to (excluding) 6.6.103 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.7 up to (excluding) 6.12.43 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.16 up to (excluding) 6.16.1 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.13 up to (excluding) 6.15.11 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 5.16 up to (excluding) 6.1.149 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 2.6.32.30 up to (excluding) 2.6.33 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 2.6.33.8 up to (excluding) 2.6.34 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 2.6.34.10 up to (excluding) 2.6.35 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 2.6.35.12 up to (excluding) 2.6.36 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 2.6.37.3 up to (excluding) 2.6.38 *cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 2.6.38.1 up to (excluding) 5.15.190 Added CPE Configuration OR *cpe:2.3:o:debian:debian_linux:11.0:*:*:*:*:*:*:* Added Reference Type kernel.org: https://git.kernel.org/stable/c/1b13b033062824495554e836a1ff5f85ccf6b039 Types: Patch Added Reference Type kernel.org: https://git.kernel.org/stable/c/2a0c0c974bea9619c6f41794775ae4b97530e0e6 Types: Patch Added Reference Type kernel.org: https://git.kernel.org/stable/c/3542c90797bc3ab83ebab54b737d751cf3682036 Types: Patch Added Reference Type kernel.org: https://git.kernel.org/stable/c/71379495ab70eaba19224bd71b5b9b399eb85e04 Types: Patch Added Reference Type kernel.org: https://git.kernel.org/stable/c/7a2125962c42d5336ca0495a9ce4cb38a63e9161 Types: Patch Added Reference Type kernel.org: https://git.kernel.org/stable/c/ea5f97dbdcb1651581a22bd10afd2f0dd9dc11d6 Types: Patch Added Reference Type kernel.org: https://git.kernel.org/stable/c/f2e467a48287c868818085aa35389a224d226732 Types: Patch Added Reference Type CVE: https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html Types: Third Party Advisory -
CVE Modified by af854a3a-2127-422b-91ae-364da2661108
Nov. 03, 2025
Action Type Old Value New Value Added Reference https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html -
CVE Modified by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Aug. 28, 2025
Action Type Old Value New Value Added Reference https://git.kernel.org/stable/c/1b13b033062824495554e836a1ff5f85ccf6b039 Added Reference https://git.kernel.org/stable/c/2a0c0c974bea9619c6f41794775ae4b97530e0e6 Added Reference https://git.kernel.org/stable/c/71379495ab70eaba19224bd71b5b9b399eb85e04 -
CVE Modified by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Aug. 20, 2025
Action Type Old Value New Value Added Reference https://git.kernel.org/stable/c/7a2125962c42d5336ca0495a9ce4cb38a63e9161 Added Reference https://git.kernel.org/stable/c/ea5f97dbdcb1651581a22bd10afd2f0dd9dc11d6 -
New CVE Received by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Aug. 19, 2025
Action Type Old Value New Value Added 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. Added Reference https://git.kernel.org/stable/c/3542c90797bc3ab83ebab54b737d751cf3682036 Added Reference https://git.kernel.org/stable/c/f2e467a48287c868818085aa35389a224d226732