Linux kernel · eventpoll: Fix semi-unbounded recursion Ensure that epoll instances can never form a graph deeper than EP_MAX_NESTS+1 links
Affects linuxSource GCVE Database
Mentioned vulnerabilities
Not known to be exploited · CVSS 7.8 Medium · patch available : update linux when convenient.
Data as of 25 Oct 2026, 19:02 UTC
- EPSS
- 0.1% chance of exploitation in 30 days – higher than 7% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HExploitation evidence
Disclosed: evidence found.
CVE published 19 Aug 2025
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 2026-10-25.
What to do
Affected software
| Product | Affected | Fixed in |
|---|---|---|
Red Hatredhat/kernelpkg:rpm/redhat/kernelOther threats | Affected
| Fixed in– |
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
Red Hat has released updated kernel packages that address these vulnerabilities. Users should apply the security update for Red Hat Enterprise Linux 10 as detailed in the advisory (RHSA-2025:21463) and reboot their systems to ensure the fixes take effect. No additional mitigations are indicated or required beyond applying the official update and rebooting.
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.
References
- access.redhat.com/errata/RHSA-2025:21463 (opens in a new tab)
- access.redhat.com/security/updates/classification/ (opens in a new tab)
- bugzilla.redhat.com/show_bug.cgi?id=2389491 (opens in a new tab)
- bugzilla.redhat.com/show_bug.cgi?id=2396934 (opens in a new tab)
- bugzilla.redhat.com/show_bug.cgi?id=2400593 (opens in a new tab)
- bugzilla.redhat.com/show_bug.cgi?id=2401414 (opens in a new tab)
- security.access.redhat.com/data/csaf/v2/advisories/2025/rhsa-2025_21463.json (opens in a new tab)
- ubuntu.com/security/CVE-2025-38614 (opens in a new tab)
- cve.org/CVERecord?id=CVE-2025-38614 (opens in a new tab)
- git.kernel.org/linus/f2e467a48287c868818085aa35389a224d226732 (opens in a new tab)
- git.kernel.org/stable/c/3542c90797bc3ab83ebab54b737d751cf3682036 (opens in a new tab)
- git.kernel.org/stable/c/f2e467a48287c868818085aa35389a224d226732 (opens in a new tab)
- ubuntu.com/security/notices/USN-7909-1 (opens in a new tab)
- ubuntu.com/security/notices/USN-7909-2 (opens in a new tab)
- ubuntu.com/security/notices/USN-7909-3 (opens in a new tab)
- ubuntu.com/security/notices/USN-7910-1 (opens in a new tab)
- ubuntu.com/security/notices/USN-7909-4 (opens in a new tab)
- ubuntu.com/security/notices/USN-7910-2 (opens in a new tab)
- ubuntu.com/security/notices/USN-7933-1 (opens in a new tab)
- ubuntu.com/security/notices/USN-7909-5 (opens in a new tab)
- ubuntu.com/security/notices/USN-7938-1 (opens in a new tab)
- ubuntu.com/security/notices/USN-8028-1 (opens in a new tab)
- ubuntu.com/security/notices/USN-8028-2 (opens in a new tab)
- ubuntu.com/security/notices/USN-8031-1 (opens in a new tab)
- ubuntu.com/security/notices/USN-8028-3 (opens in a new tab)
- ubuntu.com/security/notices/USN-8028-4 (opens in a new tab)
- ubuntu.com/security/notices/USN-8028-5 (opens in a new tab)