CWE-617
AllowedReachable Assertion
Abstraction: Base · Status: Draft
The product contains an assert() or similar statement that can be triggered by an attacker, which leads to an application exit or other behavior that is more severe than necessary.
989 vulnerabilities reference this CWE, most recent first.
GHSA-229X-W52J-6F5M
Vulnerability from github – Published: 2025-12-29 09:30 – Updated: 2026-02-24 09:31A flaw has been found in Open5GS up to 2.7.5. This affects the function decode_ipv6_header/ogs_pfcp_pdr_rule_find_by_packet of the file lib/pfcp/rule-match.c of the component PFCP Session Establishment Request Handler. Executing manipulation can lead to reachable assertion. It is possible to launch the attack remotely. The exploit has been published and may be used. This patch is called b72d8349980076e2c033c8324f07747a86eea4f8. Applying a patch is advised to resolve this issue.
{
"affected": [],
"aliases": [
"CVE-2025-15176"
],
"database_specific": {
"cwe_ids": [
"CWE-617"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-29T07:15:54Z",
"severity": "MODERATE"
},
"details": "A flaw has been found in Open5GS up to 2.7.5. This affects the function decode_ipv6_header/ogs_pfcp_pdr_rule_find_by_packet of the file lib/pfcp/rule-match.c of the component PFCP Session Establishment Request Handler. Executing manipulation can lead to reachable assertion. It is possible to launch the attack remotely. The exploit has been published and may be used. This patch is called b72d8349980076e2c033c8324f07747a86eea4f8. Applying a patch is advised to resolve this issue.",
"id": "GHSA-229x-w52j-6f5m",
"modified": "2026-02-24T09:31:19Z",
"published": "2025-12-29T09:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-15176"
},
{
"type": "WEB",
"url": "https://github.com/open5gs/open5gs/issues/4180"
},
{
"type": "WEB",
"url": "https://github.com/open5gs/open5gs/issues/4180#issue-3666760066"
},
{
"type": "WEB",
"url": "https://github.com/open5gs/open5gs/issues/4180#issuecomment-3615555671"
},
{
"type": "WEB",
"url": "https://github.com/open5gs/open5gs/commit/b72d8349980076e2c033c8324f07747a86eea4f8"
},
{
"type": "WEB",
"url": "https://github.com/open5gs/open5gs"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.338561"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.338561"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.719830"
}
],
"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:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-22J3-3Q48-2RMJ
Vulnerability from github – Published: 2026-06-08 21:31 – Updated: 2026-06-08 21:31Improper validation of packet length during tls-crypt-v2 key extraction in OpenVPN 2.6.0 through 2.6.19 and 2.7_alpha1 through 2.7.1 allows authenticated attackers to trigger a fatal assertion and cause a denial of service via a specially crafted packet.
{
"affected": [],
"aliases": [
"CVE-2026-35058"
],
"database_specific": {
"cwe_ids": [
"CWE-617"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-08T20:17:00Z",
"severity": "MODERATE"
},
"details": "Improper validation of packet length during tls-crypt-v2 key extraction in OpenVPN 2.6.0 through 2.6.19 and 2.7_alpha1 through 2.7.1 allows authenticated attackers to trigger a fatal assertion and cause a denial of service via a specially crafted packet.",
"id": "GHSA-22j3-3q48-2rmj",
"modified": "2026-06-08T21:31:50Z",
"published": "2026-06-08T21:31:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35058"
},
{
"type": "WEB",
"url": "https://community.openvpn.net/ReleaseHistory#openvpn-2620-released-22-april-2026"
},
{
"type": "WEB",
"url": "https://community.openvpn.net/ReleaseHistory#openvpn-272-released-22-april-2026"
},
{
"type": "WEB",
"url": "https://community.openvpn.net/Security%20Announcements/CVE-2026-35058"
},
{
"type": "WEB",
"url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2026-2381"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-23WJ-R557-8C5P
Vulnerability from github – Published: 2022-05-13 01:49 – Updated: 2022-05-13 01:49tinyexr 0.9.5 has an assertion failure in DecodePixelData in tinyexr.h.
{
"affected": [],
"aliases": [
"CVE-2018-12687"
],
"database_specific": {
"cwe_ids": [
"CWE-617"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-06-22T19:29:00Z",
"severity": "HIGH"
},
"details": "tinyexr 0.9.5 has an assertion failure in DecodePixelData in tinyexr.h.",
"id": "GHSA-23wj-r557-8c5p",
"modified": "2022-05-13T01:49:38Z",
"published": "2022-05-13T01:49:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-12687"
},
{
"type": "WEB",
"url": "https://github.com/syoyo/tinyexr/issues/84"
}
],
"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-2475-53VW-VP25
Vulnerability from github – Published: 2022-09-16 22:16 – Updated: 2022-09-19 19:24Impact
The implementation of AvgPoolGrad does not fully validate the input orig_input_shape. This results in a CHECK failure which can be used to trigger a denial of service attack:
import tensorflow as tf
ksize = [1, 2, 2, 1]
strides = [1, 2, 2, 1]
padding = "VALID"
data_format = "NHWC"
orig_input_shape = tf.constant(-536870912, shape=[4], dtype=tf.int32)
grad = tf.constant(.0890338004362538, shape=[1,5,7,1], dtype=tf.float64)
tf.raw_ops.AvgPoolGrad(orig_input_shape=orig_input_shape, grad=grad, ksize=ksize, strides=strides, padding=padding, data_format=data_format)
Patches
We have patched the issue in GitHub commit 3a6ac52664c6c095aa2b114e742b0aa17fdce78f.
The fix will be included in TensorFlow 2.10.0. We will also cherrypick this commit on TensorFlow 2.9.1, TensorFlow 2.8.1, and TensorFlow 2.7.2, as these are also affected and still in supported range.
For more information
Please consult our security guide for more information regarding the security model and how to contact us with issues and questions.
Attribution
This vulnerability has been reported by Neophytos Christou, Secure Systems Labs, Brown University.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.7.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow"
},
"ranges": [
{
"events": [
{
"introduced": "2.8.0"
},
{
"fixed": "2.8.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow"
},
"ranges": [
{
"events": [
{
"introduced": "2.9.0"
},
{
"fixed": "2.9.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-cpu"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.7.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-cpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.8.0"
},
{
"fixed": "2.8.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-cpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.9.0"
},
{
"fixed": "2.9.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-gpu"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.7.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-gpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.8.0"
},
{
"fixed": "2.8.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-gpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.9.0"
},
{
"fixed": "2.9.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-35968"
],
"database_specific": {
"cwe_ids": [
"CWE-617"
],
"github_reviewed": true,
"github_reviewed_at": "2022-09-16T22:16:52Z",
"nvd_published_at": "2022-09-16T21:15:00Z",
"severity": "MODERATE"
},
"details": "### Impact\nThe implementation of `AvgPoolGrad` does not fully validate the input `orig_input_shape`. This results in a `CHECK` failure which can be used to trigger a denial of service attack:\n```python\nimport tensorflow as tf\n\nksize = [1, 2, 2, 1]\nstrides = [1, 2, 2, 1]\npadding = \"VALID\"\ndata_format = \"NHWC\"\norig_input_shape = tf.constant(-536870912, shape=[4], dtype=tf.int32)\ngrad = tf.constant(.0890338004362538, shape=[1,5,7,1], dtype=tf.float64)\ntf.raw_ops.AvgPoolGrad(orig_input_shape=orig_input_shape, grad=grad, ksize=ksize, strides=strides, padding=padding, data_format=data_format)\n```\n\n### Patches\nWe have patched the issue in GitHub commit [3a6ac52664c6c095aa2b114e742b0aa17fdce78f](https://github.com/tensorflow/tensorflow/commit/3a6ac52664c6c095aa2b114e742b0aa17fdce78f).\n\nThe fix will be included in TensorFlow 2.10.0. We will also cherrypick this commit on TensorFlow 2.9.1, TensorFlow 2.8.1, and TensorFlow 2.7.2, as these are also affected and still in supported range.\n\n\n### For more information\nPlease consult [our security guide](https://github.com/tensorflow/tensorflow/blob/master/SECURITY.md) for more information regarding the security model and how to contact us with issues and questions.\n\n\n### Attribution\nThis vulnerability has been reported by Neophytos Christou, Secure Systems Labs, Brown University.\n",
"id": "GHSA-2475-53vw-vp25",
"modified": "2022-09-19T19:24:49Z",
"published": "2022-09-16T22:16:52Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/tensorflow/tensorflow/security/advisories/GHSA-2475-53vw-vp25"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-35968"
},
{
"type": "WEB",
"url": "https://github.com/tensorflow/tensorflow/commit/3a6ac52664c6c095aa2b114e742b0aa17fdce78f"
},
{
"type": "PACKAGE",
"url": "https://github.com/tensorflow/tensorflow"
},
{
"type": "WEB",
"url": "https://github.com/tensorflow/tensorflow/releases/tag/v2.10.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "TensorFlow vulnerable to `CHECK` fail in `AvgPoolGrad`"
}
GHSA-24P2-J2JR-386W
Vulnerability from github – Published: 2026-02-26 15:20 – Updated: 2026-02-26 15:20Summary
A security review of the psd_tools.compression module (conducted against the fix/invalid-rle-compression branch, commits 7490ffa–2a006f5) identified the following pre-existing issues. The two findings introduced and fixed by those commits (Cython buffer overflow, IndexError on lone repeat header) are excluded from this report.
Findings
1. Unguarded zlib.decompress — ZIP bomb / memory exhaustion (Medium)
Location: src/psd_tools/compression/__init__.py, lines 159 and 162
result = zlib.decompress(data) # Compression.ZIP
decompressed = zlib.decompress(data) # Compression.ZIP_WITH_PREDICTION
zlib.decompress is called without a max_length cap. A crafted PSD file containing a ZIP-compressed channel whose compressed payload expands to gigabytes would exhaust process memory before any limit is enforced. The RLE path is not vulnerable to this because the decoder pre-allocates exactly row_size × height bytes; the ZIP path has no equivalent ceiling.
Impact: Denial-of-service / OOM crash when processing untrusted PSD files.
Suggested mitigation: Pass a reasonable max_length to zlib.decompress, derived from the expected width * height * depth // 8 byte count already computed in decompress().
2. No upper-bound validation on image dimensions before allocation (Low)
Location: src/psd_tools/compression/__init__.py, lines 138 and 193
length = width * height * max(1, depth // 8) # decompress()
row_size = max(width * depth // 8, 1) # decode_rle()
Neither width, height, nor depth are range-checked before these values drive memory allocation. The PSD format (version 2 / PSB) permits dimensions up to 300,000 × 300,000 pixels; a 4-channel 32-bit image at that size would require ~144 TB to hold. While the OS/Python allocator will reject such a request, there is no early, explicit guard that produces a clean, user-facing error.
Impact: Uncontrolled allocation attempt from a malformed or adversarially crafted PSB file; hard crash rather than a recoverable error.
Suggested mitigation: Validate width, height, and depth against known PSD/PSB limits before entering decompression, and raise a descriptive ValueError early.
3. assert used as a runtime integrity check (Low)
Location: src/psd_tools/compression/__init__.py, line 170
assert len(result) == length, "len=%d, expected=%d" % (len(result), length)
This assertion can be silently disabled by running the interpreter with -O (or -OO), which strips all assert statements. If the assertion ever becomes relevant (e.g., after future refactoring), disabling it would allow a length mismatch to propagate silently into downstream image compositing.
Impact: Loss of an integrity guard in optimised deployments.
Suggested mitigation: Replace with an explicit if + raise ValueError(...).
4. cdef int indices vs. Py_ssize_t size type mismatch in Cython decoder (Low)
Location: src/psd_tools/compression/_rle.pyx, lines 18–20
cdef int i = 0
cdef int j = 0
cdef int length = data.shape[0]
All loop indices are C signed int (32-bit). The size parameter is Py_ssize_t (64-bit on modern platforms). The comparison j < size promotes j to Py_ssize_t, but if j wraps due to a row size exceeding INT_MAX (~2.1 GB), the resulting comparison is undefined behaviour in C. In practice, row sizes are bounded by PSD/PSB dimension limits and are unreachable at this scale; however, the mismatch is a latent defect if the function is ever called directly with large synthetic inputs.
Impact: Theoretical infinite loop or UB at >2 GB row sizes; not reachable from standard PSD/PSB parsing.
Suggested mitigation: Change cdef int i, j, length to cdef Py_ssize_t.
5. Silent data degradation not surfaced to callers (Informational)
Location: src/psd_tools/compression/__init__.py, lines 144–157
The tolerant RLE decoder (introduced in 2a006f5) replaces malformed channel data with zero-padded (black) pixels and emits a logger.warning. This is the correct trade-off over crashing, but the warning is only observable if the caller has configured a log handler. The public PSDImage API does not surface channel-level decode failures to the user in any other way.
Impact: A user parsing a silently corrupt file gets a visually wrong image with no programmatic signal to check.
Suggested mitigation: Consider exposing a per-channel decode-error flag or raising a distinct warning category that users can filter or escalate via the warnings module.
6. encode() zero-length return type inconsistency in Cython (Informational)
Location: src/psd_tools/compression/_rle.pyx, lines 66–67
if length == 0:
return data # returns a memoryview, not an explicit std::string
All other return paths return an explicit cdef string result. This path returns data (a const unsigned char[:] memoryview) and relies on Cython's implicit coercion to bytes. It is functionally equivalent today but is semantically inconsistent and fragile if Cython's coercion rules change in a future version.
Impact: Potential silent breakage in future Cython versions; not a current security issue.
Suggested mitigation: Replace return data with return result (the already-declared empty string).
Environment
- Branch:
fix/invalid-rle-compression - Reviewed commits:
7490ffa,2a006f5 - Python: 3.x (Cython extension compiled for CPython)
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "psd-tools"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.12.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-27809"
],
"database_specific": {
"cwe_ids": [
"CWE-190",
"CWE-409",
"CWE-617",
"CWE-704",
"CWE-755",
"CWE-789"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-26T15:20:51Z",
"nvd_published_at": "2026-02-26T00:16:26Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nA security review of the `psd_tools.compression` module (conducted against the `fix/invalid-rle-compression` branch, commits `7490ffa`\u2013`2a006f5`) identified the following pre-existing issues. The two findings introduced and **fixed** by those commits (Cython buffer overflow, `IndexError` on lone repeat header) are excluded from this report.\n\n---\n\n## Findings\n\n### 1. Unguarded `zlib.decompress` \u2014 ZIP bomb / memory exhaustion (Medium)\n\n**Location**: `src/psd_tools/compression/__init__.py`, lines 159 and 162\n\n```python\nresult = zlib.decompress(data) # Compression.ZIP\ndecompressed = zlib.decompress(data) # Compression.ZIP_WITH_PREDICTION\n```\n\n`zlib.decompress` is called without a `max_length` cap. A crafted PSD file containing a ZIP-compressed channel whose compressed payload expands to gigabytes would exhaust process memory before any limit is enforced. The RLE path is not vulnerable to this because the decoder pre-allocates exactly `row_size \u00d7 height` bytes; the ZIP path has no equivalent ceiling.\n\n**Impact**: Denial-of-service / OOM crash when processing untrusted PSD files.\n\n**Suggested mitigation**: Pass a reasonable `max_length` to `zlib.decompress`, derived from the expected `width * height * depth // 8` byte count already computed in `decompress()`.\n\n---\n\n### 2. No upper-bound validation on image dimensions before allocation (Low)\n\n**Location**: `src/psd_tools/compression/__init__.py`, lines 138 and 193\n\n```python\nlength = width * height * max(1, depth // 8) # decompress()\nrow_size = max(width * depth // 8, 1) # decode_rle()\n```\n\nNeither `width`, `height`, nor `depth` are range-checked before these values drive memory allocation. The PSD format (version 2 / PSB) permits dimensions up to 300,000 \u00d7 300,000 pixels; a 4-channel 32-bit image at that size would require ~144 TB to hold. While the OS/Python allocator will reject such a request, there is no early, explicit guard that produces a clean, user-facing error.\n\n**Impact**: Uncontrolled allocation attempt from a malformed or adversarially crafted PSB file; hard crash rather than a recoverable error.\n\n**Suggested mitigation**: Validate `width`, `height`, and `depth` against known PSD/PSB limits before entering decompression, and raise a descriptive `ValueError` early.\n\n---\n\n### 3. `assert` used as a runtime integrity check (Low)\n\n**Location**: `src/psd_tools/compression/__init__.py`, line 170\n\n```python\nassert len(result) == length, \"len=%d, expected=%d\" % (len(result), length)\n```\n\nThis assertion can be silently disabled by running the interpreter with `-O` (or `-OO`), which strips all `assert` statements. If the assertion ever becomes relevant (e.g., after future refactoring), disabling it would allow a length mismatch to propagate silently into downstream image compositing.\n\n**Impact**: Loss of an integrity guard in optimised deployments.\n\n**Suggested mitigation**: Replace with an explicit `if` + `raise ValueError(...)`.\n\n---\n\n### 4. `cdef int` indices vs. `Py_ssize_t size` type mismatch in Cython decoder (Low)\n\n**Location**: `src/psd_tools/compression/_rle.pyx`, lines 18\u201320\n\n```cython\ncdef int i = 0\ncdef int j = 0\ncdef int length = data.shape[0]\n```\n\nAll loop indices are C `signed int` (32-bit). The `size` parameter is `Py_ssize_t` (64-bit on modern platforms). The comparison `j \u003c size` promotes `j` to `Py_ssize_t`, but if `j` wraps due to a row size exceeding `INT_MAX` (~2.1 GB), the resulting comparison is undefined behaviour in C. In practice, row sizes are bounded by PSD/PSB dimension limits and are unreachable at this scale; however, the mismatch is a latent defect if the function is ever called directly with large synthetic inputs.\n\n**Impact**: Theoretical infinite loop or UB at \u003e2 GB row sizes; not reachable from standard PSD/PSB parsing.\n\n**Suggested mitigation**: Change `cdef int i`, `j`, `length` to `cdef Py_ssize_t`.\n\n---\n\n### 5. Silent data degradation not surfaced to callers (Informational)\n\n**Location**: `src/psd_tools/compression/__init__.py`, lines 144\u2013157\n\nThe tolerant RLE decoder (introduced in `2a006f5`) replaces malformed channel data with zero-padded (black) pixels and emits a `logger.warning`. This is the correct trade-off over crashing, but the warning is only observable if the caller has configured a log handler. The public `PSDImage` API does not surface channel-level decode failures to the user in any other way.\n\n**Impact**: A user parsing a silently corrupt file gets a visually wrong image with no programmatic signal to check.\n\n**Suggested mitigation**: Consider exposing a per-channel decode-error flag or raising a distinct warning category that users can filter or escalate via the `warnings` module.\n\n---\n\n### 6. `encode()` zero-length return type inconsistency in Cython (Informational)\n\n**Location**: `src/psd_tools/compression/_rle.pyx`, lines 66\u201367\n\n```cython\nif length == 0:\n return data # returns a memoryview, not an explicit std::string\n```\n\nAll other return paths return an explicit `cdef string result`. This path returns `data` (a `const unsigned char[:]` memoryview) and relies on Cython\u0027s implicit coercion to `bytes`. It is functionally equivalent today but is semantically inconsistent and fragile if Cython\u0027s coercion rules change in a future version.\n\n**Impact**: Potential silent breakage in future Cython versions; not a current security issue.\n\n**Suggested mitigation**: Replace `return data` with `return result` (the already-declared empty `string`).\n\n---\n\n## Environment\n\n- Branch: `fix/invalid-rle-compression`\n- Reviewed commits: `7490ffa`, `2a006f5`\n- Python: 3.x (Cython extension compiled for CPython)",
"id": "GHSA-24p2-j2jr-386w",
"modified": "2026-02-26T15:20:51Z",
"published": "2026-02-26T15:20:51Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/psd-tools/psd-tools/security/advisories/GHSA-24p2-j2jr-386w"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27809"
},
{
"type": "WEB",
"url": "https://github.com/psd-tools/psd-tools/commit/6c0a78f195b5942757886a1863793fd5946c1fb1"
},
{
"type": "PACKAGE",
"url": "https://github.com/psd-tools/psd-tools"
},
{
"type": "WEB",
"url": "https://github.com/psd-tools/psd-tools/releases/tag/v1.12.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N/E:U",
"type": "CVSS_V4"
}
],
"summary": "psd-tools: Compression module has unguarded zlib decompression, missing dimension validation, and hardening gaps"
}
GHSA-24W8-46CP-J5F8
Vulnerability from github – Published: 2024-05-20 12:30 – Updated: 2024-11-06 00:31In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Fix WARN_ON in iommu probe path
Commit 1a75cc710b95 ("iommu/vt-d: Use rbtree to track iommu probed devices") adds all devices probed by the iommu driver in a rbtree indexed by the source ID of each device. It assumes that each device has a unique source ID. This assumption is incorrect and the VT-d spec doesn't state this requirement either.
The reason for using a rbtree to track devices is to look up the device with PCI bus and devfunc in the paths of handling ATS invalidation time out error and the PRI I/O page faults. Both are PCI ATS feature related.
Only track the devices that have PCI ATS capabilities in the rbtree to avoid unnecessary WARN_ON in the iommu probe path. Otherwise, on some platforms below kernel splat will be displayed and the iommu probe results in failure.
WARNING: CPU: 3 PID: 166 at drivers/iommu/intel/iommu.c:158 intel_iommu_probe_device+0x319/0xd90 Call Trace: ? __warn+0x7e/0x180 ? intel_iommu_probe_device+0x319/0xd90 ? report_bug+0x1f8/0x200 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? intel_iommu_probe_device+0x319/0xd90 ? debug_mutex_init+0x37/0x50 __iommu_probe_device+0xf2/0x4f0 iommu_probe_device+0x22/0x70 iommu_bus_notifier+0x1e/0x40 notifier_call_chain+0x46/0x150 blocking_notifier_call_chain+0x42/0x60 bus_notify+0x2f/0x50 device_add+0x5ed/0x7e0 platform_device_add+0xf5/0x240 mfd_add_devices+0x3f9/0x500 ? preempt_count_add+0x4c/0xa0 ? up_write+0xa2/0x1b0 ? __debugfs_create_file+0xe3/0x150 intel_lpss_probe+0x49f/0x5b0 ? pci_conf1_write+0xa3/0xf0 intel_lpss_pci_probe+0xcf/0x110 [intel_lpss_pci] pci_device_probe+0x95/0x120 really_probe+0xd9/0x370 ? __pfxdriverattach+0x10/0x10 driver_probe_device+0x73/0x150 driver_probe_device+0x19/0xa0 __driver_attach+0xb6/0x180 ? __pfxdriverattach+0x10/0x10 bus_for_each_dev+0x77/0xd0 bus_add_driver+0x114/0x210 driver_register+0x5b/0x110 ? pfx_intel_lpss_pci_driver_init+0x10/0x10 [intel_lpss_pci] do_one_initcall+0x57/0x2b0 ? kmalloc_trace+0x21e/0x280 ? do_init_module+0x1e/0x210 do_init_module+0x5f/0x210 load_module+0x1d37/0x1fc0 ? init_module_from_file+0x86/0xd0 init_module_from_file+0x86/0xd0 idempotent_init_module+0x17c/0x230 __x64_sys_finit_module+0x56/0xb0 do_syscall_64+0x6e/0x140 entry_SYSCALL_64_after_hwframe+0x71/0x79
{
"affected": [],
"aliases": [
"CVE-2024-35957"
],
"database_specific": {
"cwe_ids": [
"CWE-617"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-20T10:15:10Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\niommu/vt-d: Fix WARN_ON in iommu probe path\n\nCommit 1a75cc710b95 (\"iommu/vt-d: Use rbtree to track iommu probed\ndevices\") adds all devices probed by the iommu driver in a rbtree\nindexed by the source ID of each device. It assumes that each device\nhas a unique source ID. This assumption is incorrect and the VT-d\nspec doesn\u0027t state this requirement either.\n\nThe reason for using a rbtree to track devices is to look up the device\nwith PCI bus and devfunc in the paths of handling ATS invalidation time\nout error and the PRI I/O page faults. Both are PCI ATS feature related.\n\nOnly track the devices that have PCI ATS capabilities in the rbtree to\navoid unnecessary WARN_ON in the iommu probe path. Otherwise, on some\nplatforms below kernel splat will be displayed and the iommu probe results\nin failure.\n\n WARNING: CPU: 3 PID: 166 at drivers/iommu/intel/iommu.c:158 intel_iommu_probe_device+0x319/0xd90\n Call Trace:\n \u003cTASK\u003e\n ? __warn+0x7e/0x180\n ? intel_iommu_probe_device+0x319/0xd90\n ? report_bug+0x1f8/0x200\n ? handle_bug+0x3c/0x70\n ? exc_invalid_op+0x18/0x70\n ? asm_exc_invalid_op+0x1a/0x20\n ? intel_iommu_probe_device+0x319/0xd90\n ? debug_mutex_init+0x37/0x50\n __iommu_probe_device+0xf2/0x4f0\n iommu_probe_device+0x22/0x70\n iommu_bus_notifier+0x1e/0x40\n notifier_call_chain+0x46/0x150\n blocking_notifier_call_chain+0x42/0x60\n bus_notify+0x2f/0x50\n device_add+0x5ed/0x7e0\n platform_device_add+0xf5/0x240\n mfd_add_devices+0x3f9/0x500\n ? preempt_count_add+0x4c/0xa0\n ? up_write+0xa2/0x1b0\n ? __debugfs_create_file+0xe3/0x150\n intel_lpss_probe+0x49f/0x5b0\n ? pci_conf1_write+0xa3/0xf0\n intel_lpss_pci_probe+0xcf/0x110 [intel_lpss_pci]\n pci_device_probe+0x95/0x120\n really_probe+0xd9/0x370\n ? __pfx___driver_attach+0x10/0x10\n __driver_probe_device+0x73/0x150\n driver_probe_device+0x19/0xa0\n __driver_attach+0xb6/0x180\n ? __pfx___driver_attach+0x10/0x10\n bus_for_each_dev+0x77/0xd0\n bus_add_driver+0x114/0x210\n driver_register+0x5b/0x110\n ? __pfx_intel_lpss_pci_driver_init+0x10/0x10 [intel_lpss_pci]\n do_one_initcall+0x57/0x2b0\n ? kmalloc_trace+0x21e/0x280\n ? do_init_module+0x1e/0x210\n do_init_module+0x5f/0x210\n load_module+0x1d37/0x1fc0\n ? init_module_from_file+0x86/0xd0\n init_module_from_file+0x86/0xd0\n idempotent_init_module+0x17c/0x230\n __x64_sys_finit_module+0x56/0xb0\n do_syscall_64+0x6e/0x140\n entry_SYSCALL_64_after_hwframe+0x71/0x79",
"id": "GHSA-24w8-46cp-j5f8",
"modified": "2024-11-06T00:31:53Z",
"published": "2024-05-20T12:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35957"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/89436f4f54125b1297aec1f466efd8acb4ec613d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fba8ca3e6f608b92e54271fdbd3ce569361939fc"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-24WM-5MGW-39C9
Vulnerability from github – Published: 2022-05-24 19:05 – Updated: 2022-05-24 19:05There is an Assertion in 'context_p->next_scanner_info_p->type == SCANNER_TYPE_FUNCTION' in parser_parse_function_arguments in JerryScript 2.2.0.
{
"affected": [],
"aliases": [
"CVE-2020-23320"
],
"database_specific": {
"cwe_ids": [
"CWE-617"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-06-10T23:15:00Z",
"severity": "HIGH"
},
"details": "There is an Assertion in \u0027context_p-\u003enext_scanner_info_p-\u003etype == SCANNER_TYPE_FUNCTION\u0027 in parser_parse_function_arguments in JerryScript 2.2.0.",
"id": "GHSA-24wm-5mgw-39c9",
"modified": "2022-05-24T19:05:13Z",
"published": "2022-05-24T19:05:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-23320"
},
{
"type": "WEB",
"url": "https://github.com/jerryscript-project/jerryscript/issues/3835"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-264V-M8FM-76JM
Vulnerability from github – Published: 2026-04-22 19:20 – Updated: 2026-04-27 16:22Impact
HistoryTreeProof::verify panics on a malformed proof where history.len() != positions.len() due to assert_eq!(history.len(), positions.len()).
The proof object is derived from untrusted p2p responses (ResponseTransactionsProof.proof) and is therefore attacker-controlled at the network boundary until validated. A malicious peer could trigger a crash by returning a crafted inclusion proof with a length mismatch.
Patches
The patch for this vulnerability is included as part of v1.3.0.
Workarounds
No known workarounds know.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "nimiq-transaction"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "0.2.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-34067"
],
"database_specific": {
"cwe_ids": [
"CWE-617"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-22T19:20:50Z",
"nvd_published_at": "2026-04-22T21:17:07Z",
"severity": "LOW"
},
"details": "### Impact\n`HistoryTreeProof::verify` panics on a malformed proof where `history.len() != positions.len()` due to `assert_eq!(history.len(), positions.len())`. \n\nThe proof object is derived from untrusted p2p responses (`ResponseTransactionsProof.proof`) and is therefore attacker-controlled at the network boundary until validated. A malicious peer could trigger a crash by returning a crafted inclusion proof with a length mismatch.\n\n### Patches\n[The patch for this vulnerability](https://github.com/nimiq/core-rs-albatross/commit/6ff0800e8e031363e787c827d8d033e5694e4e6a) is included as part of [v1.3.0](https://github.com/nimiq/core-rs-albatross/releases/tag/v1.3.0).\n\n### Workarounds\nNo known workarounds know.",
"id": "GHSA-264v-m8fm-76jm",
"modified": "2026-04-27T16:22:44Z",
"published": "2026-04-22T19:20:50Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nimiq/core-rs-albatross/security/advisories/GHSA-264v-m8fm-76jm"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34067"
},
{
"type": "WEB",
"url": "https://github.com/nimiq/core-rs-albatross/pull/3659"
},
{
"type": "WEB",
"url": "https://github.com/nimiq/core-rs-albatross/commit/6ff0800e8e031363e787c827d8d033e5694e4e6a"
},
{
"type": "PACKAGE",
"url": "https://github.com/nimiq/core-rs-albatross"
},
{
"type": "WEB",
"url": "https://github.com/nimiq/core-rs-albatross/releases/tag/v1.3.0"
}
],
"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": "nimiq-transaction: Panic via `HistoryTreeProof` length mismatch"
}
GHSA-26M6-RW98-F5XX
Vulnerability from github – Published: 2022-05-13 01:42 – Updated: 2022-05-13 01:42The WriteBlob function in MagickCore/blob.c in ImageMagick before 6.9.8-10 and 7.x before 7.6.0-0 allows remote attackers to cause a denial of service (assertion failure and application exit) via a crafted file.
{
"affected": [],
"aliases": [
"CVE-2017-11524"
],
"database_specific": {
"cwe_ids": [
"CWE-617"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-07-23T03:29:00Z",
"severity": "MODERATE"
},
"details": "The WriteBlob function in MagickCore/blob.c in ImageMagick before 6.9.8-10 and 7.x before 7.6.0-0 allows remote attackers to cause a denial of service (assertion failure and application exit) via a crafted file.",
"id": "GHSA-26m6-rw98-f5xx",
"modified": "2022-05-13T01:42:24Z",
"published": "2022-05-13T01:42:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-11524"
},
{
"type": "WEB",
"url": "https://github.com/ImageMagick/ImageMagick/issues/506"
},
{
"type": "WEB",
"url": "https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867798"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/99934"
}
],
"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"
}
]
}
GHSA-26M7-X2XV-CJ76
Vulnerability from github – Published: 2022-05-24 19:20 – Updated: 2022-05-24 19:20Possible denial of service scenario due to improper input validation of received NAS OTA message in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile
{
"affected": [],
"aliases": [
"CVE-2021-1982"
],
"database_specific": {
"cwe_ids": [
"CWE-617"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-11-12T07:15:00Z",
"severity": "HIGH"
},
"details": "Possible denial of service scenario due to improper input validation of received NAS OTA message in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile",
"id": "GHSA-26m7-x2xv-cj76",
"modified": "2022-05-24T19:20:34Z",
"published": "2022-05-24T19:20:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-1982"
},
{
"type": "WEB",
"url": "https://www.qualcomm.com/company/product-security/bulletins/november-2021-bulletin"
}
],
"schema_version": "1.4.0",
"severity": []
}
Mitigation
Make sensitive open/close operation non reachable by directly user-controlled data (e.g. open/close resources)
Mitigation
Strategy: Input Validation
Perform input validation on user data.
No CAPEC attack patterns related to this CWE.