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.
1057 vulnerabilities reference this CWE, most recent first.
GHSA-PWFH-2PJ9-F3RC
Vulnerability from github – Published: 2024-06-13 18:31 – Updated: 2024-08-28 15:31libyaml v0.2.5 is vulnerable to DDOS. Affected by this issue is the function yaml_parser_parse of the file /src/libyaml/src/parser.c.
{
"affected": [],
"aliases": [
"CVE-2024-35328"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-13T16:15:11Z",
"severity": "HIGH"
},
"details": "libyaml v0.2.5 is vulnerable to DDOS. Affected by this issue is the function yaml_parser_parse of the file /src/libyaml/src/parser.c.",
"id": "GHSA-pwfh-2pj9-f3rc",
"modified": "2024-08-28T15:31:13Z",
"published": "2024-06-13T18:31:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35328"
},
{
"type": "WEB",
"url": "https://github.com/idhyt/pocs/blob/main/libyaml/CVE-2024-35328.c"
},
{
"type": "WEB",
"url": "https://github.com/idhyt/pocs/tree/main/libyaml"
}
],
"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"
}
]
}
GHSA-PX9G-8HGV-JVG2
Vulnerability from github – Published: 2022-10-06 19:53 – Updated: 2022-10-06 19:53Impact
Reader::read_from_container can cause an infinite loop when a crafted PNG file is given.
Patches
Version 0.5.3 includes the fix.
Workarounds
No workaround is available. Applications that do not pass files with the PNG signature to Reader::read_from_container are not affected.
References
- https://github.com/kamadak/exif-rs/security/advisories/GHSA-px9g-8hgv-jvg2
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21235
For more information
If you have any questions or comments about this advisory: * Open an issue in github.com/kamadak/exif-rs
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "kamadak-exif"
},
"ranges": [
{
"events": [
{
"introduced": "0.5.2"
},
{
"fixed": "0.5.3"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"0.5.2"
]
}
],
"aliases": [
"CVE-2021-21235"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-835"
],
"github_reviewed": true,
"github_reviewed_at": "2022-10-06T19:53:39Z",
"nvd_published_at": "2021-01-06T02:15:00Z",
"severity": "MODERATE"
},
"details": "### Impact\nReader::read_from_container can cause an infinite loop when a crafted PNG file is given.\n\n### Patches\nVersion 0.5.3 includes the fix.\n\n### Workarounds\nNo workaround is available.\nApplications that do not pass files with the PNG signature to Reader::read_from_container are not affected.\n\n### References\n* \u003chttps://github.com/kamadak/exif-rs/security/advisories/GHSA-px9g-8hgv-jvg2\u003e\n* \u003chttps://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21235\u003e\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [github.com/kamadak/exif-rs](https://github.com/kamadak/exif-rs)",
"id": "GHSA-px9g-8hgv-jvg2",
"modified": "2022-10-06T19:53:39Z",
"published": "2022-10-06T19:53:39Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/kamadak/exif-rs/security/advisories/GHSA-px9g-8hgv-jvg2"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21235"
},
{
"type": "WEB",
"url": "https://github.com/kamadak/exif-rs/commit/1b05eab57e484cd7d576d4357b9cda7fdc57df8c"
},
{
"type": "WEB",
"url": "https://github.com/kamadak/exif-rs/commit/f21df24616ea611c5d5d0e0e2f8042eb74d5ff48"
},
{
"type": "WEB",
"url": "https://crates.io/crates/kamadak-exif"
},
{
"type": "PACKAGE",
"url": "https://github.com/kamadak/exif-rs"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2021-0143.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "kamadak-exif vulnerable to Infinite loop when parsing PNG files"
}
GHSA-PXH5-6RRC-8RJV
Vulnerability from github – Published: 2026-05-20 15:35 – Updated: 2026-05-20 15:35Impact
Unauthenticated denial of service.
Summary
When installing provider or module packages from attacker-controlled servers, the server may cause tofu initto enter an infinite loop sending garbage data to that server.
Those who depend on modules or providers served from untrusted third-party servers may experience denial of service due to tofu init failing to complete successfully. Other processes running on the same computer as OpenTofu may also fail or have their performance degraded due to the depletion of shared system resources.
These vulnerabilities do not permit arbitrary code execution or allow disclosure of confidential information.
Details
OpenTofu relies a third-party implementations of HTTP2 from the standard library of the Go programming language.
The Go project has recently published the following advisory for that implementation, which indirectly affects OpenTofu's behavior:
- CVE-2026-33814: Infinite loop in HTTP/2 transport when given bad SETTINGS_MAX_FRAME_SIZE in net/http/internal/http2 in golang.org/x/net
OpenTofu's threat model considers module and package dependencies to be arbitrary third-party code that operators must carefully review after installation. However, these particular problems affect the process of installing these dependencies with tofu init, and so can potentially occur before an operator has had the opportunity to review what is being installed. In particular, the described problem would occur before OpenTofu actually retrieves a dependency package and performs checksum verification, because it affect the transport of the packages rather than the content of the packages.
An attacker can exploit this by controlling the HTTP2 implementation of the server where the dependencies are hosted, causing it to send a crafted "SETTINGS" frame which sets the maximum frame size to zero.
However, the attacker must also coerce an OpenTofu operator into attempting dependency installation from the server they control. Typical use of OpenTofu already requires caution in selection of third-party dependencies because they are arbitrary code, and so the vulnerability here is only in the addition of a potential denial of service in the tofu init process, which does not execute third-party dependency code itself.
Patches
OpenTofu v1.11.8 addresses this vulnerability by being built against Go 1.25.10, which contains an improved version of the upstream implementation.
The OpenTofu v1.10 and v1.9 series are also impacted by this vulnerability. However, those series are built with a version of Go for which no upstream fix is available. Adopting Go 1.25.10 for those series would effectively end support for certain versions of macOS, and the OpenTofu Project has determined that the impact of these vulnerabilities is not high enough to justify that disruption in a patch release. For those using the OpenTofu v1.10 or v1.9 releases we recommend planning to upgrade to OpenTofu v1.11.8 in the near future, and reviewing the Workarounds section below in the meantime.
Workarounds
This vulnerability can be exploited only if an attacker can coerce an operator to add a dependency from an attacker-controlled source to their configuration before running tofu init. Those who are unable to upgrade can therefore minimize risk by reviewing new dependencies before adding them to the configuration, such as by directly fetching the relevant artifacts using software other than OpenTofu.
Successful exploitation requires that the attacker control an HTTP2 server that tofu init would contact during dependency installation. Note that OpenTofu modules can have their own dependencies on other providers and modules, so an attacker could potentially use a module served from a source such as GitHub or the OpenTofu Registry to indirectly request a module from a server they control.
References
- OpenTofu v1.11.8 Release Notes
- https://github.com/opentofu/opentofu/pull/4098
- https://github.com/opentofu/opentofu/issues/4094
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/opentofu/opentofu"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.11.8"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-20T15:35:45Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "### Impact\nUnauthenticated denial of service.\n\n### Summary\n\nWhen installing provider or module packages from attacker-controlled servers, the server may cause `tofu init`to enter an infinite loop sending garbage data to that server.\n\nThose who depend on modules or providers served from untrusted third-party servers may experience denial of service due to `tofu init` failing to complete successfully. Other processes running on the same computer as OpenTofu may also fail or have their performance degraded due to the depletion of shared system resources.\n\nThese vulnerabilities **do not** permit arbitrary code execution or allow disclosure of confidential information.\n\n### Details\n\nOpenTofu relies a third-party implementations of HTTP2 from the standard library of the Go programming language.\n\nThe Go project has recently published the following advisory for that implementation, which indirectly affects OpenTofu\u0027s behavior:\n\n- [CVE-2026-33814](https://www.cve.org/CVERecord?id=CVE-2026-33814): Infinite loop in HTTP/2 transport when given bad SETTINGS_MAX_FRAME_SIZE in net/http/internal/http2 in golang.org/x/net\n\nOpenTofu\u0027s threat model considers module and package dependencies to be arbitrary third-party code that operators must carefully review after installation. However, these particular problems affect the process of _installing_ these dependencies with `tofu init`, and so can potentially occur before an operator has had the opportunity to review what is being installed. In particular, the described problem would occur before OpenTofu actually retrieves a dependency package and performs checksum verification, because it affect the transport of the packages rather than the content of the packages.\n\nAn attacker can exploit this by controlling the HTTP2 implementation of the server where the dependencies are hosted, causing it to send a crafted \"SETTINGS\" frame which sets the maximum frame size to zero.\n\nHowever, the attacker must also coerce an OpenTofu operator into attempting dependency installation from the server they control. Typical use of OpenTofu already requires caution in selection of third-party dependencies because they are arbitrary code, and so the vulnerability here is only in the addition of a potential denial of service in the `tofu init` process, which does not execute third-party dependency code itself.\n\n### Patches\n\nOpenTofu v1.11.8 addresses this vulnerability by being built against Go 1.25.10, which contains an improved version of the upstream implementation.\n\nThe OpenTofu v1.10 and v1.9 series are also impacted by this vulnerability. However, those series are built with a version of Go for which no upstream fix is available. Adopting Go 1.25.10 for those series would effectively end support for certain versions of macOS, and the OpenTofu Project has determined that the impact of these vulnerabilities is not high enough to justify that disruption in a patch release. For those using the OpenTofu v1.10 or v1.9 releases we recommend planning to upgrade to OpenTofu v1.11.8 in the near future, and reviewing the Workarounds section below in the meantime.\n\n### Workarounds\n\nThis vulnerability can be exploited only if an attacker can coerce an operator to add a dependency from an attacker-controlled source to their configuration before running `tofu init`. Those who are unable to upgrade can therefore minimize risk by reviewing new dependencies before adding them to the configuration, such as by directly fetching the relevant artifacts using software other than OpenTofu.\n\nSuccessful exploitation requires that the attacker control an HTTP2 server that `tofu init` would contact during dependency installation. Note that OpenTofu modules can have their own dependencies on other providers and modules, so an attacker could potentially use a module served from a source such as GitHub or the OpenTofu Registry to indirectly request a module from a server they control.\n\n### References\n\n- [OpenTofu v1.11.8 Release Notes](https://github.com/opentofu/opentofu/releases/tag/v1.11.8)\n- https://github.com/opentofu/opentofu/pull/4098\n- https://github.com/opentofu/opentofu/issues/4094",
"id": "GHSA-pxh5-6rrc-8rjv",
"modified": "2026-05-20T15:35:45Z",
"published": "2026-05-20T15:35:45Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/opentofu/opentofu/security/advisories/GHSA-pxh5-6rrc-8rjv"
},
{
"type": "WEB",
"url": "https://github.com/opentofu/opentofu/issues/4094"
},
{
"type": "WEB",
"url": "https://github.com/opentofu/opentofu/pull/4098"
},
{
"type": "PACKAGE",
"url": "https://github.com/opentofu/opentofu"
},
{
"type": "WEB",
"url": "https://github.com/opentofu/opentofu/releases/tag/v1.11.8"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "OpenTofu: Excessive resource usage in \"tofu init\" when installing dependencies from attacker-controlled server"
}
GHSA-PXW4-94J3-V9PF
Vulnerability from github – Published: 2025-04-11 14:09 – Updated: 2025-04-11 14:09SurrealDB allows authenticated users with OWNER or EDITOR permissions at the root, database or namespace levels to define their own database functions using the DEFINE FUNCTION statement
A custom database function comprises a name together with a function body. In the function body, the user programs the functionality of the function in terms of SurrealQL. The language includes a FOR keyword, used to implement for-loops.
Whilst the parser and interpreter constrain the number of iterations for a single for-loop, nesting several for-loops with a large number of iterations is possible. Thus, an attacker could define a function that comprises several nested for-loops with an iteration count of 1.000.000 each.
Executing the function will consume all the CPU time of the server, timeouts configured will not break the CPU consumption, and the function execution monopolizes all CPU time of the SurrealDB server, effectively preventing the server from executing functions, queries, commands of other users, or allowing further connections being established to the server.
Terminating the stuck server requires manual intervention which forces a quit on the server process, as the server application is not responsive any longer.
This issue was discovered and patched during an code audit and penetration test of SurrealDB by cure53, the severity defined within cure53's preliminary finding is high, matched by our CVSS v4 assessment.
Impact
Denial of Service vulnerability resulting in a stuck SurrealDB server requiring manual restart.
Patches
A patch has been introduced that adds a check in the ForEachStatement that checks if the context has been cancelled or timed out for every iteration.
- Versions 2.0.5, 2.1.5, 2.2.2, and later are not affected by this issue.
Workarounds
For SurrealDB users that are unable to upgrade, consider setting the --allow-functions and/or --deny-functions options or corresponding SURREAL_CAPS_ALLOW_FUNC and/or SURREAL_CAPS_DENY_FUNC environment variables, documented within capabilities, to either block all custom functions, or only allow trusted functions to execute.
References
SurrealQL Documentation - DEFINE FUNCTION Statement SurrealQL Documentation - FOR Statement SurrealDB Documentation - Capabilities SurrealDB Documentation - Environment variables #5597
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "surrealdb"
},
"ranges": [
{
"events": [
{
"introduced": "2.2.0"
},
{
"fixed": "2.2.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "surrealdb"
},
"ranges": [
{
"events": [
{
"introduced": "2.1.0"
},
{
"fixed": "2.1.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "surrealdb"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.0.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": true,
"github_reviewed_at": "2025-04-11T14:09:14Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "SurrealDB allows authenticated users with `OWNER` or `EDITOR` permissions at the root, database or namespace levels to define their own database functions using the `DEFINE FUNCTION` statement\n\nA custom database function comprises a name together with a function body. In the function body, the user programs the functionality of the function in terms of SurrealQL. The language includes a `FOR` keyword, used to implement for-loops.\n\nWhilst the parser and interpreter constrain the number of iterations for a single for-loop, nesting several for-loops with a large number of iterations is possible. Thus, an attacker could define a function that comprises several nested for-loops with an iteration count of 1.000.000 each. \n\nExecuting the function will consume all the CPU time of the server, timeouts configured will not break the CPU consumption, and the function execution monopolizes all CPU time of the SurrealDB server, effectively preventing the server from executing functions, queries, commands of other users, or allowing further connections being established to the server.\n\nTerminating the stuck server requires manual intervention which forces a quit on the server process, as the server application is not responsive any longer.\n\nThis issue was discovered and patched during an code audit and penetration test of SurrealDB by cure53, the severity defined within cure53\u0027s preliminary finding is high, matched by our CVSS v4 assessment.\n\n### Impact\nDenial of Service vulnerability resulting in a stuck SurrealDB server requiring manual restart.\n\n### Patches\nA patch has been introduced that adds a check in the `ForEachStatement` that checks if the context has been cancelled or timed out for every iteration.\n\n- Versions 2.0.5, 2.1.5, 2.2.2, and later are not affected by this issue.\n\n### Workarounds\nFor SurrealDB users that are unable to upgrade, consider setting the `--allow-functions` and/or `--deny-functions` options or corresponding `SURREAL_CAPS_ALLOW_FUNC` and/or `SURREAL_CAPS_DENY_FUNC` environment variables, documented within [capabilities](https://surrealdb.com/docs/surrealdb/security/capabilities#functions), to either block all custom functions, or only allow trusted functions to execute. \n\n\n### References\n[SurrealQL Documentation - DEFINE FUNCTION Statement](https://surrealdb.com/docs/surrealql/statements/define/function)\n[SurrealQL Documentation - FOR Statement](https://surrealdb.com/docs/surrealql/statements/for)\n[SurrealDB Documentation - Capabilities](https://surrealdb.com/docs/surrealdb/security/capabilities#functions)\n[SurrealDB Documentation - Environment variables](https://surrealdb.com/docs/surrealdb/cli/env#command-environment-variables)\n[#5597](https://github.com/surrealdb/surrealdb/pull/5597)",
"id": "GHSA-pxw4-94j3-v9pf",
"modified": "2025-04-11T14:09:14Z",
"published": "2025-04-11T14:09:14Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/surrealdb/surrealdb/security/advisories/GHSA-pxw4-94j3-v9pf"
},
{
"type": "WEB",
"url": "https://github.com/surrealdb/surrealdb/pull/5597"
},
{
"type": "PACKAGE",
"url": "https://github.com/surrealdb/surrealdb"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "SurrealDB CPU exhaustion via custom functions result in total DoS"
}
GHSA-Q249-C8F4-3H57
Vulnerability from github – Published: 2022-10-17 12:00 – Updated: 2022-10-20 19:00An external attacker is able to send a specially crafted email (with many recipients) and trigger a potential DoS of the system
{
"affected": [],
"aliases": [
"CVE-2022-39052"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-10-17T09:15:00Z",
"severity": "MODERATE"
},
"details": "An external attacker is able to send a specially crafted email (with many recipients) and trigger a potential DoS of the system",
"id": "GHSA-q249-c8f4-3h57",
"modified": "2022-10-20T19:00:36Z",
"published": "2022-10-17T12:00:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39052"
},
{
"type": "WEB",
"url": "https://otrs.com/release-notes/otrs-security-advisory-2022-13"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-Q24C-8CPC-8X8C
Vulnerability from github – Published: 2022-05-24 19:13 – Updated: 2022-05-24 19:13Loop with unreachable exit condition may occur due to improper handling of unsupported input in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon IoT, Snapdragon Voice & Music, Snapdragon Wearables
{
"affected": [],
"aliases": [
"CVE-2021-1914"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-09-08T12:15:00Z",
"severity": "HIGH"
},
"details": "Loop with unreachable exit condition may occur due to improper handling of unsupported input in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon IoT, Snapdragon Voice \u0026 Music, Snapdragon Wearables",
"id": "GHSA-q24c-8cpc-8x8c",
"modified": "2022-05-24T19:13:53Z",
"published": "2022-05-24T19:13:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-1914"
},
{
"type": "WEB",
"url": "https://www.qualcomm.com/company/product-security/bulletins/august-2021-bulletin"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-Q2PP-5WRH-VP88
Vulnerability from github – Published: 2022-05-13 01:46 – Updated: 2025-04-20 03:33In Wireshark 2.2.0 to 2.2.4 and 2.0.0 to 2.0.10, there is an RTMPT dissector infinite loop, triggered by packet injection or a malformed capture file. This was addressed in epan/dissectors/packet-rtmpt.c by properly incrementing a certain sequence value.
{
"affected": [],
"aliases": [
"CVE-2017-6472"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-03-04T03:59:00Z",
"severity": "HIGH"
},
"details": "In Wireshark 2.2.0 to 2.2.4 and 2.0.0 to 2.0.10, there is an RTMPT dissector infinite loop, triggered by packet injection or a malformed capture file. This was addressed in epan/dissectors/packet-rtmpt.c by properly incrementing a certain sequence value.",
"id": "GHSA-q2pp-5wrh-vp88",
"modified": "2025-04-20T03:33:38Z",
"published": "2022-05-13T01:46:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-6472"
},
{
"type": "WEB",
"url": "https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13347"
},
{
"type": "WEB",
"url": "https://code.wireshark.org/review/gitweb?p=wireshark.git%3Ba=commit%3Bh=2b3a0909beff8963b390034c594e0b6be6a4e531"
},
{
"type": "WEB",
"url": "https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=2b3a0909beff8963b390034c594e0b6be6a4e531"
},
{
"type": "WEB",
"url": "https://www.wireshark.org/security/wnpa-sec-2017-04.html"
},
{
"type": "WEB",
"url": "http://www.debian.org/security/2017/dsa-3811"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/96571"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-Q2RP-27FW-94MP
Vulnerability from github – Published: 2022-05-24 16:44 – Updated: 2023-06-12 09:30An improperly performed length calculation on a buffer in PlaintextRecordLayer could lead to an infinite loop and denial-of-service based on user input. This issue affected versions of fizz prior to v2019.03.04.00.
{
"affected": [],
"aliases": [
"CVE-2019-3560"
],
"database_specific": {
"cwe_ids": [
"CWE-131",
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-04-29T16:29:00Z",
"severity": "MODERATE"
},
"details": "An improperly performed length calculation on a buffer in PlaintextRecordLayer could lead to an infinite loop and denial-of-service based on user input. This issue affected versions of fizz prior to v2019.03.04.00.",
"id": "GHSA-q2rp-27fw-94mp",
"modified": "2023-06-12T09:30:18Z",
"published": "2022-05-24T16:44:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-3560"
},
{
"type": "WEB",
"url": "https://github.com/facebookincubator/fizz/commit/40bbb161e72fb609608d53b9d64c56bb961a6ee2"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/172836/polkit-Authentication-Bypass.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"
}
]
}
GHSA-Q392-394V-MXRH
Vulnerability from github – Published: 2026-04-30 06:30 – Updated: 2026-04-30 06:30UDS protocol dissector infinite loop in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service
{
"affected": [],
"aliases": [
"CVE-2026-7375"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-30T06:16:16Z",
"severity": "MODERATE"
},
"details": "UDS protocol dissector infinite loop in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service",
"id": "GHSA-q392-394v-mxrh",
"modified": "2026-04-30T06:30:30Z",
"published": "2026-04-30T06:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-7375"
},
{
"type": "WEB",
"url": "https://gitlab.com/wireshark/wireshark/-/work_items/21225"
},
{
"type": "WEB",
"url": "https://www.wireshark.org/security/wnpa-sec-2026-50.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-Q44M-58PC-8RR7
Vulnerability from github – Published: 2025-06-18 12:30 – Updated: 2025-11-14 18:31In the Linux kernel, the following vulnerability has been resolved:
kprobes: don't call disarm_kprobe() for disabled kprobes
The assumption in __disable_kprobe() is wrong, and it could try to disarm an already disarmed kprobe and fire the WARN_ONCE() below. [0] We can easily reproduce this issue.
- Write 0 to /sys/kernel/debug/kprobes/enabled.
# echo 0 > /sys/kernel/debug/kprobes/enabled
- Run execsnoop. At this time, one kprobe is disabled.
# /usr/share/bcc/tools/execsnoop & [1] 2460 PCOMM PID PPID RET ARGS
# cat /sys/kernel/debug/kprobes/list ffffffff91345650 r __x64_sys_execve+0x0 [FTRACE] ffffffff91345650 k __x64_sys_execve+0x0 [DISABLED][FTRACE]
- Write 1 to /sys/kernel/debug/kprobes/enabled, which changes kprobes_all_disarmed to false but does not arm the disabled kprobe.
# echo 1 > /sys/kernel/debug/kprobes/enabled
# cat /sys/kernel/debug/kprobes/list ffffffff91345650 r __x64_sys_execve+0x0 [FTRACE] ffffffff91345650 k __x64_sys_execve+0x0 [DISABLED][FTRACE]
- Kill execsnoop, when __disable_kprobe() calls disarm_kprobe() for the disabled kprobe and hits the WARN_ONCE() in __disarm_kprobe_ftrace().
# fg /usr/share/bcc/tools/execsnoop ^C
Actually, WARN_ONCE() is fired twice, and __unregister_kprobe_top() misses some cleanups and leaves the aggregated kprobe in the hash table. Then, __unregister_trace_kprobe() initialises tk->rp.kp.list and creates an infinite loop like this.
aggregated kprobe.list -> kprobe.list -. ^ | '.__.'
In this situation, these commands fall into the infinite loop and result in RCU stall or soft lockup.
cat /sys/kernel/debug/kprobes/list : show_kprobe_addr() enters into the infinite loop with RCU.
/usr/share/bcc/tools/execsnoop : warn_kprobe_rereg() holds kprobe_mutex, and __get_valid_kprobe() is stuck in the loop.
To avoid the issue, make sure we don't call disarm_kprobe() for disabled kprobes.
[0] Failed to disarm kprobe-ftrace at __x64_sys_execve+0x0/0x40 (error -2) WARNING: CPU: 6 PID: 2460 at kernel/kprobes.c:1130 __disarm_kprobe_ftrace.isra.19 (kernel/kprobes.c:1129) Modules linked in: ena CPU: 6 PID: 2460 Comm: execsnoop Not tainted 5.19.0+ #28 Hardware name: Amazon EC2 c5.2xlarge/, BIOS 1.0 10/16/2017 RIP: 0010:__disarm_kprobe_ftrace.isra.19 (kernel/kprobes.c:1129) Code: 24 8b 02 eb c1 80 3d c4 83 f2 01 00 75 d4 48 8b 75 00 89 c2 48 c7 c7 90 fa 0f 92 89 04 24 c6 05 ab 83 01 e8 e4 94 f0 ff <0f> 0b 8b 04 24 eb b1 89 c6 48 c7 c7 60 fa 0f 92 89 04 24 e8 cc 94 RSP: 0018:ffff9e6ec154bd98 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffff930f7b00 RCX: 0000000000000001 RDX: 0000000080000001 RSI: ffffffff921461c5 RDI: 00000000ffffffff RBP: ffff89c504286da8 R08: 0000000000000000 R09: c0000000fffeffff R10: 0000000000000000 R11: ffff9e6ec154bc28 R12: ffff89c502394e40 R13: ffff89c502394c00 R14: ffff9e6ec154bc00 R15: 0000000000000000 FS: 00007fe800398740(0000) GS:ffff89c812d80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000c00057f010 CR3: 0000000103b54006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: __disable_kprobe (kernel/kprobes.c:1716) disable_kprobe (kernel/kprobes.c:2392) __disable_trace_kprobe (kernel/trace/trace_kprobe.c:340) disable_trace_kprobe (kernel/trace/trace_kprobe.c:429) perf_trace_event_unreg.isra.2 (./include/linux/tracepoint.h:93 kernel/trace/trace_event_perf.c:168) perf_kprobe_destroy (kernel/trace/trace_event_perf.c:295) _free_event (kernel/events/core.c:4971) perf_event_release_kernel (kernel/events/core.c:5176) perf_release (kernel/events/core.c:5186) __fput (fs/file_table.c:321) task_work_run (./include/linux/ ---truncated---
{
"affected": [],
"aliases": [
"CVE-2022-50008"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-18T11:15:28Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nkprobes: don\u0027t call disarm_kprobe() for disabled kprobes\n\nThe assumption in __disable_kprobe() is wrong, and it could try to disarm\nan already disarmed kprobe and fire the WARN_ONCE() below. [0] We can\neasily reproduce this issue.\n\n1. Write 0 to /sys/kernel/debug/kprobes/enabled.\n\n # echo 0 \u003e /sys/kernel/debug/kprobes/enabled\n\n2. Run execsnoop. At this time, one kprobe is disabled.\n\n # /usr/share/bcc/tools/execsnoop \u0026\n [1] 2460\n PCOMM PID PPID RET ARGS\n\n # cat /sys/kernel/debug/kprobes/list\n ffffffff91345650 r __x64_sys_execve+0x0 [FTRACE]\n ffffffff91345650 k __x64_sys_execve+0x0 [DISABLED][FTRACE]\n\n3. Write 1 to /sys/kernel/debug/kprobes/enabled, which changes\n kprobes_all_disarmed to false but does not arm the disabled kprobe.\n\n # echo 1 \u003e /sys/kernel/debug/kprobes/enabled\n\n # cat /sys/kernel/debug/kprobes/list\n ffffffff91345650 r __x64_sys_execve+0x0 [FTRACE]\n ffffffff91345650 k __x64_sys_execve+0x0 [DISABLED][FTRACE]\n\n4. Kill execsnoop, when __disable_kprobe() calls disarm_kprobe() for the\n disabled kprobe and hits the WARN_ONCE() in __disarm_kprobe_ftrace().\n\n # fg\n /usr/share/bcc/tools/execsnoop\n ^C\n\nActually, WARN_ONCE() is fired twice, and __unregister_kprobe_top() misses\nsome cleanups and leaves the aggregated kprobe in the hash table. Then,\n__unregister_trace_kprobe() initialises tk-\u003erp.kp.list and creates an\ninfinite loop like this.\n\n aggregated kprobe.list -\u003e kprobe.list -.\n ^ |\n \u0027.__.\u0027\n\nIn this situation, these commands fall into the infinite loop and result\nin RCU stall or soft lockup.\n\n cat /sys/kernel/debug/kprobes/list : show_kprobe_addr() enters into the\n infinite loop with RCU.\n\n /usr/share/bcc/tools/execsnoop : warn_kprobe_rereg() holds kprobe_mutex,\n and __get_valid_kprobe() is stuck in\n\t\t\t\t the loop.\n\nTo avoid the issue, make sure we don\u0027t call disarm_kprobe() for disabled\nkprobes.\n\n[0]\nFailed to disarm kprobe-ftrace at __x64_sys_execve+0x0/0x40 (error -2)\nWARNING: CPU: 6 PID: 2460 at kernel/kprobes.c:1130 __disarm_kprobe_ftrace.isra.19 (kernel/kprobes.c:1129)\nModules linked in: ena\nCPU: 6 PID: 2460 Comm: execsnoop Not tainted 5.19.0+ #28\nHardware name: Amazon EC2 c5.2xlarge/, BIOS 1.0 10/16/2017\nRIP: 0010:__disarm_kprobe_ftrace.isra.19 (kernel/kprobes.c:1129)\nCode: 24 8b 02 eb c1 80 3d c4 83 f2 01 00 75 d4 48 8b 75 00 89 c2 48 c7 c7 90 fa 0f 92 89 04 24 c6 05 ab 83 01 e8 e4 94 f0 ff \u003c0f\u003e 0b 8b 04 24 eb b1 89 c6 48 c7 c7 60 fa 0f 92 89 04 24 e8 cc 94\nRSP: 0018:ffff9e6ec154bd98 EFLAGS: 00010282\nRAX: 0000000000000000 RBX: ffffffff930f7b00 RCX: 0000000000000001\nRDX: 0000000080000001 RSI: ffffffff921461c5 RDI: 00000000ffffffff\nRBP: ffff89c504286da8 R08: 0000000000000000 R09: c0000000fffeffff\nR10: 0000000000000000 R11: ffff9e6ec154bc28 R12: ffff89c502394e40\nR13: ffff89c502394c00 R14: ffff9e6ec154bc00 R15: 0000000000000000\nFS: 00007fe800398740(0000) GS:ffff89c812d80000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000000c00057f010 CR3: 0000000103b54006 CR4: 00000000007706e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n\u003cTASK\u003e\n __disable_kprobe (kernel/kprobes.c:1716)\n disable_kprobe (kernel/kprobes.c:2392)\n __disable_trace_kprobe (kernel/trace/trace_kprobe.c:340)\n disable_trace_kprobe (kernel/trace/trace_kprobe.c:429)\n perf_trace_event_unreg.isra.2 (./include/linux/tracepoint.h:93 kernel/trace/trace_event_perf.c:168)\n perf_kprobe_destroy (kernel/trace/trace_event_perf.c:295)\n _free_event (kernel/events/core.c:4971)\n perf_event_release_kernel (kernel/events/core.c:5176)\n perf_release (kernel/events/core.c:5186)\n __fput (fs/file_table.c:321)\n task_work_run (./include/linux/\n---truncated---",
"id": "GHSA-q44m-58pc-8rr7",
"modified": "2025-11-14T18:31:25Z",
"published": "2025-06-18T12:30:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50008"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/19cd630712e7c13a3dedfc6986a9b983fed6fd98"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/55c7a91527343d2e0b5647cc308c6e04ddd2aa52"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6f3c1bc22fc2165461883f506b4d2c3594bd7137"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/744b0d3080709a172f0408aedabd1cedd24c2ee6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9c80e79906b4ca440d09e7f116609262bb747909"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b474ff1b20951f1eac75d100a93861e6da2b522b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bc3188d8a3b8c08c306a4c851ddb2c92ba4599ca"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fc91d2db55acdaf0c0075b624e572d3520ca3bc3"
}
],
"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"
}
]
}
No mitigation information available for this CWE.
No CAPEC attack patterns related to this CWE.