CWE-835
AllowedLoop with Unreachable Exit Condition ('Infinite Loop')
Abstraction: Base · Status: Incomplete
The product contains an iteration or loop with an exit condition that cannot be reached, i.e., an infinite loop.
1052 vulnerabilities reference this CWE, most recent first.
GHSA-M6JJ-C3PV-CG65
Vulnerability from github – Published: 2026-04-22 15:31 – Updated: 2026-07-14 15:31In the Linux kernel, the following vulnerability has been resolved:
ext4: avoid infinite loops caused by residual data
On the mkdir/mknod path, when mapping logical blocks to physical blocks, if inserting a new extent into the extent tree fails (in this example, because the file system disabled the huge file feature when marking the inode as dirty), ext4_ext_map_blocks() only calls ext4_free_blocks() to reclaim the physical block without deleting the corresponding data in the extent tree. This causes subsequent mkdir operations to reference the previously reclaimed physical block number again, even though this physical block is already being used by the xattr block. Therefore, a situation arises where both the directory and xattr are using the same buffer head block in memory simultaneously.
The above causes ext4_xattr_block_set() to enter an infinite loop about "inserted" and cannot release the inode lock, ultimately leading to the 143s blocking problem mentioned in [1].
If the metadata is corrupted, then trying to remove some extent space can do even more harm. Also in case EXT4_GET_BLOCKS_DELALLOC_RESERVE was passed, remove space wrongly update quota information. Jan Kara suggests distinguishing between two cases:
1) The error is ENOSPC or EDQUOT - in this case the filesystem is fully consistent and we must maintain its consistency including all the accounting. However these errors can happen only early before we've inserted the extent into the extent tree. So current code works correctly for this case.
2) Some other error - this means metadata is corrupted. We should strive to do as few modifications as possible to limit damage. So I'd just skip freeing of allocated blocks.
[1] INFO: task syz.0.17:5995 blocked for more than 143 seconds. Call Trace: inode_lock_nested include/linux/fs.h:1073 [inline] __start_dirop fs/namei.c:2923 [inline] start_dirop fs/namei.c:2934 [inline]
{
"affected": [],
"aliases": [
"CVE-2026-31448"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-22T14:16:38Z",
"severity": "CRITICAL"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: avoid infinite loops caused by residual data\n\nOn the mkdir/mknod path, when mapping logical blocks to physical blocks,\nif inserting a new extent into the extent tree fails (in this example,\nbecause the file system disabled the huge file feature when marking the\ninode as dirty), ext4_ext_map_blocks() only calls ext4_free_blocks() to\nreclaim the physical block without deleting the corresponding data in\nthe extent tree. This causes subsequent mkdir operations to reference\nthe previously reclaimed physical block number again, even though this\nphysical block is already being used by the xattr block. Therefore, a\nsituation arises where both the directory and xattr are using the same\nbuffer head block in memory simultaneously.\n\nThe above causes ext4_xattr_block_set() to enter an infinite loop about\n\"inserted\" and cannot release the inode lock, ultimately leading to the\n143s blocking problem mentioned in [1].\n\nIf the metadata is corrupted, then trying to remove some extent space\ncan do even more harm. Also in case EXT4_GET_BLOCKS_DELALLOC_RESERVE\nwas passed, remove space wrongly update quota information.\nJan Kara suggests distinguishing between two cases:\n\n1) The error is ENOSPC or EDQUOT - in this case the filesystem is fully\nconsistent and we must maintain its consistency including all the\naccounting. However these errors can happen only early before we\u0027ve\ninserted the extent into the extent tree. So current code works correctly\nfor this case.\n\n2) Some other error - this means metadata is corrupted. We should strive to\ndo as few modifications as possible to limit damage. So I\u0027d just skip\nfreeing of allocated blocks.\n\n[1]\nINFO: task syz.0.17:5995 blocked for more than 143 seconds.\nCall Trace:\n inode_lock_nested include/linux/fs.h:1073 [inline]\n __start_dirop fs/namei.c:2923 [inline]\n start_dirop fs/namei.c:2934 [inline]",
"id": "GHSA-m6jj-c3pv-cg65",
"modified": "2026-07-14T15:31:51Z",
"published": "2026-04-22T15:31:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31448"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-082556.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3a7667595bcad84da53fc156a418e110267c3412"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/416c86f30f91b4fb2642ef6b102596ca898f41a5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5422fe71d26d42af6c454ca9527faaad4e677d6c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/64f425b06b3bea9abc8977fd3982779b3ad070c9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c66545e83a802c3851d9be27a41c0479dd29ff0c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ecc50bfca9b5c2ee6aeef998181689b80477367b"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-M6XR-FVFG-5G64
Vulnerability from github – Published: 2026-05-19 20:09 – Updated: 2026-05-19 20:09Summary
dasel's selector lexer enters a non-terminating loop when tokenizing an unterminated regex pattern such as r/abc. A 2-byte input (r/) is sufficient to cause the tokenizer to consume 100% CPU on one core indefinitely.
I confirmed the issue on v3.3.1 (fba653c7f248aff10f2b89fca93929b64707dfc8) and on master commit 0dd6132e0c58edbd9b1a5f7ffd00dfab1e6085ad. I also verified the same code path is present in v3.0.0 (648f83baf070d9e00db8ff312febef857ec090a3). No fix is available yet.
Details
The bug is in the matchRegexPattern closure within (*Tokenizer).parseCurRune in selector/lexer/tokenize.go#L237-L247:
matchRegexPattern := func(pos int) *Token {
if p.src[pos] != 'r' || !p.peekRuneEqual(pos+1, '/') {
return nil
}
start := pos
pos += 2
for !p.peekRuneEqual(pos, '/') { // line 243
pos++
}
pos++
return ptr.To(NewToken(RegexPattern, p.src[start+2:pos-1], start, pos-start))
}
When no closing / exists, peekRuneEqual returns false when pos >= srcLen (because the bounds check at line 40 returns false for out-of-range positions). Since !false = true, the loop condition remains true and pos increments indefinitely. The function never returns.
Notably, the same function already handles unterminated quoted strings by returning UnexpectedEOFError, but the regex pattern path does not perform a similar end-of-input check.
Minimal trigger: r/ (2 bytes)
Test environment:
- MacBook Air (Apple M2), macOS / Darwin
arm64 - Go
1.26.1 - dasel
v3.3.1(fba653c7f248aff10f2b89fca93929b64707dfc8)
PoC
package main
import (
"fmt"
"runtime"
"time"
"github.com/tomwright/dasel/v3/selector/lexer"
)
func main() {
fmt.Printf("Go version: %s\n", runtime.Version())
fmt.Printf("GOARCH: %s\n", runtime.GOARCH)
fmt.Println()
for _, input := range []string{"r/unterminated", "r/"} {
fmt.Printf("Input: %s\n", input)
done := make(chan string, 1)
go func() {
t := lexer.NewTokenizer(input)
start := time.Now()
tokens, err := t.Tokenize()
elapsed := time.Since(start)
if err != nil {
done <- fmt.Sprintf("Error after %v: %v", elapsed, err)
} else {
done <- fmt.Sprintf("OK after %v: %d tokens", elapsed, len(tokens))
}
}()
select {
case result := <-done:
fmt.Println(result)
case <-time.After(5 * time.Second):
fmt.Println("CONFIRMED: did not complete within 5s; tokenizer is stuck in non-terminating loop")
}
fmt.Println()
}
}
Observed output on v3.3.1 in the test environment above:
Go version: go1.26.1
GOARCH: arm64
Input: r/unterminated
CONFIRMED: did not complete within 5s; tokenizer is stuck in non-terminating loop
Input: r/
CONFIRMED: did not complete within 5s; tokenizer is stuck in non-terminating loop
Impact
An attacker who can control or influence the selector/query string passed to dasel can cause the tokenizer to enter a non-terminating loop. The affected process consumes 100% CPU on one core and does not make progress until externally terminated.
The selector string is typically provided by the application developer, but there are deployment scenarios where it may be attacker-influenced: - Web applications using dasel for dynamic data querying - Applications that construct selectors from user input - Shared tooling environments where selectors are passed as parameters
Suggested Fix
The regex scanner should bounds-check and return an error on unterminated regex literals, consistent with unterminated quoted strings. Since matchRegexPattern currently returns *Token, the fix also requires changing the function signature to propagate errors. For example:
matchRegexPattern := func(pos int) (*Token, error) {
if p.src[pos] != 'r' || !p.peekRuneEqual(pos+1, '/') {
return nil, nil
}
start := pos
pos += 2
for pos < p.srcLen && p.src[pos] != '/' {
pos++
}
if pos >= p.srcLen {
return nil, &UnexpectedEOFError{Pos: pos}
}
pos++
return ptr.To(NewToken(RegexPattern, p.src[start+2:pos-1], start, pos-start)), nil
}
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/tomwright/dasel/v3"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.10.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-46378"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-19T20:09:20Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\n`dasel`\u0027s selector lexer enters a non-terminating loop when tokenizing an unterminated regex pattern such as `r/abc`. A 2-byte input (`r/`) is sufficient to cause the tokenizer to consume 100% CPU on one core indefinitely.\n\nI confirmed the issue on `v3.3.1` (`fba653c7f248aff10f2b89fca93929b64707dfc8`) and on `master` commit `0dd6132e0c58edbd9b1a5f7ffd00dfab1e6085ad`. I also verified the same code path is present in `v3.0.0` (`648f83baf070d9e00db8ff312febef857ec090a3`). No fix is available yet.\n\n### Details\n\nThe bug is in the `matchRegexPattern` closure within `(*Tokenizer).parseCurRune` in [`selector/lexer/tokenize.go#L237-L247`](https://github.com/TomWright/dasel/blob/fba653c7f248aff10f2b89fca93929b64707dfc8/selector/lexer/tokenize.go#L237-L247):\n\n```go\nmatchRegexPattern := func(pos int) *Token {\n if p.src[pos] != \u0027r\u0027 || !p.peekRuneEqual(pos+1, \u0027/\u0027) {\n return nil\n }\n start := pos\n pos += 2\n for !p.peekRuneEqual(pos, \u0027/\u0027) { // line 243\n pos++\n }\n pos++\n return ptr.To(NewToken(RegexPattern, p.src[start+2:pos-1], start, pos-start))\n}\n```\n\nWhen no closing `/` exists, [`peekRuneEqual`](https://github.com/TomWright/dasel/blob/fba653c7f248aff10f2b89fca93929b64707dfc8/selector/lexer/tokenize.go#L39-L43) returns `false` when `pos \u003e= srcLen` (because the bounds check at line 40 returns `false` for out-of-range positions). Since `!false = true`, the loop condition remains true and `pos` increments indefinitely. The function never returns.\n\nNotably, the same function already handles unterminated quoted strings by returning `UnexpectedEOFError`, but the regex pattern path does not perform a similar end-of-input check.\n\nMinimal trigger: `r/` (2 bytes)\n\nTest environment:\n\n- MacBook Air (Apple M2), macOS / Darwin `arm64`\n- Go `1.26.1`\n- dasel `v3.3.1` (`fba653c7f248aff10f2b89fca93929b64707dfc8`)\n\n### PoC\n\n```go\npackage main\n\nimport (\n\t\"fmt\"\n\t\"runtime\"\n\t\"time\"\n\n\t\"github.com/tomwright/dasel/v3/selector/lexer\"\n)\n\nfunc main() {\n\tfmt.Printf(\"Go version: %s\\n\", runtime.Version())\n\tfmt.Printf(\"GOARCH: %s\\n\", runtime.GOARCH)\n\tfmt.Println()\n\n\tfor _, input := range []string{\"r/unterminated\", \"r/\"} {\n\t\tfmt.Printf(\"Input: %s\\n\", input)\n\t\tdone := make(chan string, 1)\n\t\tgo func() {\n\t\t\tt := lexer.NewTokenizer(input)\n\t\t\tstart := time.Now()\n\t\t\ttokens, err := t.Tokenize()\n\t\t\telapsed := time.Since(start)\n\t\t\tif err != nil {\n\t\t\t\tdone \u003c- fmt.Sprintf(\"Error after %v: %v\", elapsed, err)\n\t\t\t} else {\n\t\t\t\tdone \u003c- fmt.Sprintf(\"OK after %v: %d tokens\", elapsed, len(tokens))\n\t\t\t}\n\t\t}()\n\n\t\tselect {\n\t\tcase result := \u003c-done:\n\t\t\tfmt.Println(result)\n\t\tcase \u003c-time.After(5 * time.Second):\n\t\t\tfmt.Println(\"CONFIRMED: did not complete within 5s; tokenizer is stuck in non-terminating loop\")\n\t\t}\n\t\tfmt.Println()\n\t}\n}\n```\n\nObserved output on `v3.3.1` in the test environment above:\n\n```text\nGo version: go1.26.1\nGOARCH: arm64\n\nInput: r/unterminated\nCONFIRMED: did not complete within 5s; tokenizer is stuck in non-terminating loop\n\nInput: r/\nCONFIRMED: did not complete within 5s; tokenizer is stuck in non-terminating loop\n```\n\n### Impact\n\nAn attacker who can control or influence the selector/query string passed to dasel can cause the tokenizer to enter a non-terminating loop. The affected process consumes 100% CPU on one core and does not make progress until externally terminated.\n\nThe selector string is typically provided by the application developer, but there are deployment scenarios where it may be attacker-influenced:\n- Web applications using dasel for dynamic data querying\n- Applications that construct selectors from user input\n- Shared tooling environments where selectors are passed as parameters\n\n### Suggested Fix\n\nThe regex scanner should bounds-check and return an error on unterminated regex literals, consistent with unterminated quoted strings. Since `matchRegexPattern` currently returns `*Token`, the fix also requires changing the function signature to propagate errors. For example:\n\n```go\nmatchRegexPattern := func(pos int) (*Token, error) {\n if p.src[pos] != \u0027r\u0027 || !p.peekRuneEqual(pos+1, \u0027/\u0027) {\n return nil, nil\n }\n start := pos\n pos += 2\n for pos \u003c p.srcLen \u0026\u0026 p.src[pos] != \u0027/\u0027 {\n pos++\n }\n if pos \u003e= p.srcLen {\n return nil, \u0026UnexpectedEOFError{Pos: pos}\n }\n pos++\n return ptr.To(NewToken(RegexPattern, p.src[start+2:pos-1], start, pos-start)), nil\n}\n```",
"id": "GHSA-m6xr-fvfg-5g64",
"modified": "2026-05-19T20:09:21Z",
"published": "2026-05-19T20:09:20Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/TomWright/dasel/security/advisories/GHSA-m6xr-fvfg-5g64"
},
{
"type": "WEB",
"url": "https://github.com/TomWright/dasel/commit/95f8dd3af12958bf6ca2a737b3ec0267280f86ed"
},
{
"type": "PACKAGE",
"url": "https://github.com/TomWright/dasel"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Dasel: Denial of service in dasel selector lexer due to infinite loop on unterminated regex literal"
}
GHSA-M72M-MHQ2-9P6C
Vulnerability from github – Published: 2021-08-23 19:42 – Updated: 2022-02-08 20:59Impact
What kind of vulnerability is it? Who is impacted? Those using jsoup to parse untrusted HTML or XML may be vulnerable to DOS attacks. If the parser is run on user supplied input, an attacker may supply content that causes the parser to get stuck (loop indefinitely until cancelled), to complete more slowly than usual, or to throw an unexpected exception. This effect may support a denial of service attack.
Patches
Has the problem been patched? What versions should users upgrade to? Users should upgrade to jsoup 1.14.2
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading? Users may rate limit input parsing. Users should limit the size of inputs based on system resources. Users should implement thread watchdogs to cap and timeout parse runtimes.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.jsoup:jsoup"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.14.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-37714"
],
"database_specific": {
"cwe_ids": [
"CWE-248",
"CWE-835"
],
"github_reviewed": true,
"github_reviewed_at": "2021-08-23T17:20:30Z",
"nvd_published_at": "2021-08-18T15:15:00Z",
"severity": "HIGH"
},
"details": "### Impact\n_What kind of vulnerability is it? Who is impacted?_\nThose using jsoup to parse untrusted HTML or XML may be vulnerable to DOS attacks. If the parser is run on user supplied input, an attacker may supply content that causes the parser to get stuck (loop indefinitely until cancelled), to complete more slowly than usual, or to throw an unexpected exception. This effect may support a denial of service attack.\n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\nUsers should upgrade to jsoup 1.14.2\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\nUsers may rate limit input parsing. Users should limit the size of inputs based on system resources. Users should implement thread watchdogs to cap and timeout parse runtimes.\n",
"id": "GHSA-m72m-mhq2-9p6c",
"modified": "2022-02-08T20:59:16Z",
"published": "2021-08-23T19:42:38Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/jhy/jsoup/security/advisories/GHSA-m72m-mhq2-9p6c"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-37714"
},
{
"type": "PACKAGE",
"url": "https://github.com/jhy/jsoup"
},
{
"type": "WEB",
"url": "https://jsoup.org/news/release-1.14.1"
},
{
"type": "WEB",
"url": "https://jsoup.org/news/release-1.14.2"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r215009dbf7467a9f6506d0c0024cb36cad30071010e62c9352cfaaf0@%3Cissues.maven.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r377b93d79817ce649e9e68b3456e6f499747ef1643fa987b342e082e@%3Cissues.maven.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r3d71f18adb78e50f626dde689161ca63d3b7491bd9718fcddfaecba7@%3Cissues.maven.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r50e9c9466c592ca9d707a5dea549524d19e3287da08d8392f643960e@%3Cissues.maven.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r685c5235235ad0c26e86d0ee987fb802c9675de6081dbf0516464e0b@%3Cnotifications.james.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r97404676a5cf591988faedb887d64e278f522adcaa823d89ca69defe@%3Cnotifications.james.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rc3354080fc67fb50b45b3c2d12dc4ca2a3c1c78dad3d3ba012c038aa@%3Cnotifications.james.apache.org%3E"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20220210-0022"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuapr2022.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujan2022.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujul2022.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Uncaught Exception in jsoup"
}
GHSA-M73F-CF56-RF2W
Vulnerability from github – Published: 2022-05-13 01:44 – Updated: 2022-05-13 01:44When dynamic memory allocation fails, currently the process sleeps for one second and continues with infinite loop without retrying for memory allocation in Snapdragon Automobile, Snapdragon Mobile, Snapdragon Wear in version MDM9206, MDM9607, MDM9640, MDM9650, MSM8909W, QCN5502, SD 210/SD 212/SD 205, SD 425, SD 430, SD 450, SD 600, SD 615/16/SD 415, SD 625, SD 650/52, SD 810, SD 820, SD 820A, SD 835.
{
"affected": [],
"aliases": [
"CVE-2017-18277"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-10-23T13:29:00Z",
"severity": "MODERATE"
},
"details": "When dynamic memory allocation fails, currently the process sleeps for one second and continues with infinite loop without retrying for memory allocation in Snapdragon Automobile, Snapdragon Mobile, Snapdragon Wear in version MDM9206, MDM9607, MDM9640, MDM9650, MSM8909W, QCN5502, SD 210/SD 212/SD 205, SD 425, SD 430, SD 450, SD 600, SD 615/16/SD 415, SD 625, SD 650/52, SD 810, SD 820, SD 820A, SD 835.",
"id": "GHSA-m73f-cf56-rf2w",
"modified": "2022-05-13T01:44:38Z",
"published": "2022-05-13T01:44:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-18277"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2018-07-01#qualcomm-closed-source-components"
},
{
"type": "WEB",
"url": "https://www.qualcomm.com/company/product-security/bulletins"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-M7JV-HQ7H-MQ7C
Vulnerability from github – Published: 2022-02-08 22:05 – Updated: 2026-06-11 14:30The payload length in a WebSocket frame was not correctly validated in Apache Tomcat 10.0.0-M1 to 10.0.0-M6, 9.0.0.M1 to 9.0.36, 8.5.0 to 8.5.56 and 7.0.27 to 7.0.104. Invalid payload lengths could trigger an infinite loop. Multiple requests with invalid payload lengths could lead to a denial of service.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat"
},
"ranges": [
{
"events": [
{
"introduced": "10.0.0-M1"
},
{
"fixed": "10.0.0-M7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0.M1"
},
{
"fixed": "9.0.37"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat"
},
"ranges": [
{
"events": [
{
"introduced": "8.5.0"
},
{
"fixed": "8.5.57"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.27"
},
{
"fixed": "7.0.105"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-websocket"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.27"
},
{
"fixed": "7.0.105"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-websocket"
},
"ranges": [
{
"events": [
{
"introduced": "8.5.0"
},
{
"fixed": "8.5.57"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-websocket"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0.M1"
},
{
"fixed": "9.0.37"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-websocket"
},
"ranges": [
{
"events": [
{
"introduced": "10.0.0-M1"
},
{
"fixed": "10.0.0-M7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat-websocket"
},
"ranges": [
{
"events": [
{
"introduced": "10.0.0-M1"
},
{
"fixed": "10.0.0-M7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat-websocket"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0.M1"
},
{
"fixed": "9.0.37"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat-websocket"
},
"ranges": [
{
"events": [
{
"introduced": "8.5.0"
},
{
"fixed": "8.5.57"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat-websocket"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.27"
},
{
"fixed": "7.0.105"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-13935"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": true,
"github_reviewed_at": "2021-04-12T18:44:47Z",
"nvd_published_at": "2020-07-14T15:15:00Z",
"severity": "HIGH"
},
"details": "The payload length in a WebSocket frame was not correctly validated in Apache Tomcat 10.0.0-M1 to 10.0.0-M6, 9.0.0.M1 to 9.0.36, 8.5.0 to 8.5.56 and 7.0.27 to 7.0.104. Invalid payload lengths could trigger an infinite loop. Multiple requests with invalid payload lengths could lead to a denial of service.",
"id": "GHSA-m7jv-hq7h-mq7c",
"modified": "2026-06-11T14:30:51Z",
"published": "2022-02-08T22:05:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-13935"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/12d715676038efbf9c728af10163f8277fc019d5"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/1c1c77b0efb667cea80b532440b44cea1dc427c3"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/40fa74c74822711ab878079d0a69f7357926723d"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/4c04982870d6e730c38e21e58fb653b7cf723784"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/f9f75c14678b68633f79030ddf4ff827f014cc84"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuoct2021.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuoct2020.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujan2022.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujan2021.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuapr2022.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuApr2021.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com//security-alerts/cpujul2021.html"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2020/dsa-4727"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4596-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4448-1"
},
{
"type": "WEB",
"url": "https://tomcat.apache.org/security-9.html"
},
{
"type": "WEB",
"url": "https://tomcat.apache.org/security-8.html"
},
{
"type": "WEB",
"url": "https://tomcat.apache.org/security-7.html"
},
{
"type": "WEB",
"url": "https://tomcat.apache.org/security-10.html"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20200724-0003"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2020/07/msg00017.html"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rd48c72bd3255bda87564d4da3791517c074d94f8a701f93b85752651%40%3Cannounce.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r4e5d3c09f4dd2923191e972408b40fb8b42dbff0bc7904d44b651e50@%3Cusers.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://kc.mcafee.com/corporate/index?page=content\u0026id=SB10332"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/tomcat"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2020-07/msg00084.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2020-07/msg00088.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Infinite Loop in Apache Tomcat"
}
GHSA-M842-HM2C-8XM2
Vulnerability from github – Published: 2025-08-14 18:31 – Updated: 2025-08-14 18:31A vulnerability in the IKEv2 feature of Cisco IOS Software, IOS XE Software, Secure Firewall ASA Software, and Secure FTD Software could allow an unauthenticated, remote attacker to cause the device to reload, resulting in a DoS condition.
This vulnerability is due to the improper processing of IKEv2 packets. An attacker could exploit this vulnerability by sending crafted IKEv2 packets to an affected device. A successful exploit could allow the attacker to cause an infinite loop that exhausts resources and could cause the device to reload.
{
"affected": [],
"aliases": [
"CVE-2025-20253"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-14T17:15:38Z",
"severity": "HIGH"
},
"details": "A vulnerability in the IKEv2 feature of Cisco IOS Software, IOS XE Software, Secure Firewall ASA Software, and Secure FTD Software could allow an unauthenticated, remote attacker to cause the device to reload, resulting in a DoS condition.\n\nThis vulnerability is due to the improper processing of IKEv2 packets. An attacker could exploit this vulnerability by sending crafted IKEv2 packets to an affected device. A successful exploit could allow the attacker to cause an infinite loop that exhausts resources and could cause the device to reload.",
"id": "GHSA-m842-hm2c-8xm2",
"modified": "2025-08-14T18:31:30Z",
"published": "2025-08-14T18:31:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-20253"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-asa-ftd-ios-dos-DOESHWHy"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-M89X-HF4G-3J36
Vulnerability from github – Published: 2022-05-24 17:36 – Updated: 2022-05-24 17:36An issue was discovered in picoTCP and picoTCP-NG through 1.7.0. When an unsupported TCP option with zero length is provided in an incoming TCP packet, it is possible to cause a Denial-of-Service by achieving an infinite loop in the code that parses TCP options, aka tcp_parse_options() in pico_tcp.c.
{
"affected": [],
"aliases": [
"CVE-2020-24337"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-12-11T23:15:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in picoTCP and picoTCP-NG through 1.7.0. When an unsupported TCP option with zero length is provided in an incoming TCP packet, it is possible to cause a Denial-of-Service by achieving an infinite loop in the code that parses TCP options, aka tcp_parse_options() in pico_tcp.c.",
"id": "GHSA-m89x-hf4g-3j36",
"modified": "2022-05-24T17:36:11Z",
"published": "2022-05-24T17:36:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-24337"
},
{
"type": "WEB",
"url": "https://us-cert.cisa.gov/ics/advisories/icsa-20-343-01"
},
{
"type": "WEB",
"url": "https://www.kb.cert.org/vuls/id/815128"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-M8P7-HJG2-3XQJ
Vulnerability from github – Published: 2026-02-04 18:30 – Updated: 2026-04-18 09:30In the Linux kernel, the following vulnerability has been resolved:
can: gs_usb: gs_usb_receive_bulk_callback(): unanchor URL on usb_submit_urb() error
In commit 7352e1d5932a ("can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak"), the URB was re-anchored before usb_submit_urb() in gs_usb_receive_bulk_callback() to prevent a leak of this URB during cleanup.
However, this patch did not take into account that usb_submit_urb() could fail. The URB remains anchored and usb_kill_anchored_urbs(&parent->rx_submitted) in gs_can_close() loops infinitely since the anchor list never becomes empty.
To fix the bug, unanchor the URB when an usb_submit_urb() error occurs, also print an info message.
{
"affected": [],
"aliases": [
"CVE-2026-23082"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-04T17:16:19Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncan: gs_usb: gs_usb_receive_bulk_callback(): unanchor URL on usb_submit_urb() error\n\nIn commit 7352e1d5932a (\"can: gs_usb: gs_usb_receive_bulk_callback(): fix\nURB memory leak\"), the URB was re-anchored before usb_submit_urb() in\ngs_usb_receive_bulk_callback() to prevent a leak of this URB during\ncleanup.\n\nHowever, this patch did not take into account that usb_submit_urb() could\nfail. The URB remains anchored and\nusb_kill_anchored_urbs(\u0026parent-\u003erx_submitted) in gs_can_close() loops\ninfinitely since the anchor list never becomes empty.\n\nTo fix the bug, unanchor the URB when an usb_submit_urb() error occurs,\nalso print an info message.",
"id": "GHSA-m8p7-hjg2-3xqj",
"modified": "2026-04-18T09:30:17Z",
"published": "2026-02-04T18:30:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23082"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/79a6d1bfe1148bc921b8d7f3371a7fbce44e30f7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aa8a8866c533a150be4763bcb27993603bd5426c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c3edc14da81a8d8398682f6e4ab819f09f37c0b7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c610b550ccc0438d456dfe1df9f4f36254ccaae3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ce4352057fc5a986c76ece90801b9755e7c6e56c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/da01de754e455e2598a7f1ce4ff2078c4f0ecde1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-M9V3-PQJ8-J8X7
Vulnerability from github – Published: 2022-05-13 01:07 – Updated: 2022-05-13 01:07The intel_hda_xfer function in hw/audio/intel-hda.c in QEMU (aka Quick Emulator) allows local guest OS administrators to cause a denial of service (infinite loop and CPU consumption) via an entry with the same value for buffer length and pointer position.
{
"affected": [],
"aliases": [
"CVE-2016-8909"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2016-11-04T21:59:00Z",
"severity": "MODERATE"
},
"details": "The intel_hda_xfer function in hw/audio/intel-hda.c in QEMU (aka Quick Emulator) allows local guest OS administrators to cause a denial of service (infinite loop and CPU consumption) via an entry with the same value for buffer length and pointer position.",
"id": "GHSA-m9v3-pqj8-j8x7",
"modified": "2022-05-13T01:07:30Z",
"published": "2022-05-13T01:07:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-8909"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2017:2392"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2017:2408"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2016-8909"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1388052"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2018/11/msg00038.html"
},
{
"type": "WEB",
"url": "https://lists.gnu.org/archive/html/qemu-devel/2016-10/msg04682.html"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/201611-11"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-updates/2016-12/msg00140.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2016/10/24/1"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2016/10/24/4"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/93842"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-MCQR-W7VQ-7QJV
Vulnerability from github – Published: 2022-05-13 01:17 – Updated: 2022-05-13 01:17In ImageMagick 7.0.7-16 Q16 x86_64 2017-12-22, an infinite loop vulnerability was found in the function ReadMIFFImage in coders/miff.c, which allows attackers to cause a denial of service (CPU exhaustion) via a crafted MIFF image file.
{
"affected": [],
"aliases": [
"CVE-2017-18271"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-05-18T19:29:00Z",
"severity": "HIGH"
},
"details": "In ImageMagick 7.0.7-16 Q16 x86_64 2017-12-22, an infinite loop vulnerability was found in the function ReadMIFFImage in coders/miff.c, which allows attackers to cause a denial of service (CPU exhaustion) via a crafted MIFF image file.",
"id": "GHSA-mcqr-w7vq-7qjv",
"modified": "2022-05-13T01:17:22Z",
"published": "2022-05-13T01:17:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-18271"
},
{
"type": "WEB",
"url": "https://github.com/ImageMagick/ImageMagick/issues/911"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2018/05/msg00012.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2019/05/msg00015.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2020/09/msg00007.html"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/3681-1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
No mitigation information available for this CWE.
No CAPEC attack patterns related to this CWE.