Common Weakness Enumeration
CWE-129
AllowedImproper Validation of Array Index
Abstraction: Variant · Status: Draft
The product uses untrusted input when calculating or using an array index, but the product does not validate or incorrectly validates the index to ensure the index references a valid position within the array.
745 vulnerabilities reference this CWE, most recent first.
GHSA-HWQM-QVJ9-4JR2
Vulnerability from github – Published: 2026-03-18 20:19 – Updated: 2026-03-18 20:19
VLAI
Summary
gosaml2 CBC Padding Panic — Unauthenticated Process Crash
Details
Summary
The AES-CBC decryption path in DecryptBytes() panics on crafted ciphertext whose plaintext is all zero bytes. After decryption, bytes.TrimRight(data, "\x00") empties the slice, then data[len(data)-1] panics with index out of range [-1]. There is no recover() in the library. The panic propagates through ValidateEncodedResponse and kills the goroutine (or the entire process in non-net/http servers). An attacker needs only the SP's public RSA key (published in SAML metadata) to construct the payload — no valid signature is required.
Affected Version
All versions of github.com/russellhaering/gosaml2 through latest (v0.9.0 and HEAD) that support AES-CBC encrypted assertions.
Vulnerable Code
types/encrypted_assertion.go:65-79 — DecryptBytes, AES-CBC branch:
case MethodAES128CBC, MethodAES256CBC, MethodTripleDESCBC:
if len(data)%k.BlockSize() != 0 {
return nil, fmt.Errorf("encrypted data is not a multiple of the expected CBC block size %d: actual size %d", k.BlockSize(), len(data))
}
nonce, data := data[:k.BlockSize()], data[k.BlockSize():]
c := cipher.NewCBCDecrypter(k, nonce)
c.CryptBlocks(data, data)
// Remove zero bytes
data = bytes.TrimRight(data, "\x00") // <-- empties the slice if plaintext is all zeros
// Calculate index to remove based on padding
padLength := data[len(data)-1] // <-- PANIC: index out of range [-1]
lastGoodIndex := len(data) - int(padLength)
return data[:lastGoodIndex], nil
Attack Details
| Property | Value |
|---|---|
| Attack Vector | Network (unauthenticated HTTP POST to ACS endpoint) |
| Authentication Required | None |
| Attacker Knowledge | SP's public RSA certificate (published in SAML metadata) |
| Signature Required | No — decryption happens before assertion signature validation |
| Payload Size | Single HTTP POST (~2 KB) |
| Repeatability | Unlimited — attacker can send the payload repeatedly |
| Affected Configurations | Any SP with SPKeyStore configured (encrypted assertion support) |
| Trigger Condition | AES-CBC plaintext that is all 0x00 bytes after decryption |
Impact
- Process crash: In gRPC servers, custom frameworks, CLI tools, and background workers, the unrecovered panic kills the entire OS process immediately.
- Goroutine crash: In
net/httpservers, the built-in per-goroutine recovery catches the panic, returning HTTP 500 and logging the full stack trace. The server survives but the request-handling goroutine is terminated abnormally. - Denial of service: The attack is unauthenticated and repeatable. A single crafted HTTP request is sufficient. Automated retries can keep the service down indefinitely.
- No valid signature needed: The SAML Response does not need to be signed. On the unsigned-response code path (
decode_response.go:346),decryptAssertions()is called before any assertion signature validation.
Reproduction
Prerequisites
- Docker (for the vulnerable server)
- Python 3.8+ with
cryptographyandrequestspackages
Files
| File | Description |
|---|---|
server.go |
Minimal SAML SP using gosaml2 — the victim |
poc.py |
Attacker script — builds and sends the crafted payload |
Dockerfile |
Multi-stage build for the vulnerable server |
run.sh |
Build and orchestration script |
Steps
# 1. Build the vulnerable server
./run.sh build
# 2. Start the server
./run.sh start
# 3. Run the attacker script
pip install cryptography requests
./run.sh attack
# Or do everything in one command:
./run.sh all
Expected Output
Attacker terminal (poc.py):
========================================================
CVE: CBC Padding Panic — Unauthenticated Process Crash
Target: gosaml2 (github.com/russellhaering/gosaml2)
File: types/encrypted_assertion.go:77
Impact: Remote DoS — single HTTP request kills process
========================================================
[*] Target: http://localhost:9999
[*] Checking server health...
[+] Server is alive
========================================================
Phase 1: Obtain SP public certificate from metadata
========================================================
[*] GET http://localhost:9999/metadata
[+] Retrieved SP certificate (xxx bytes)
========================================================
Phase 2: Build crafted EncryptedAssertion payload
========================================================
[+] Extracted RSA public key (size=2048 bits)
[*] Generated AES-128 key: <hex>
[+] RSA-OAEP encrypted AES key (256 bytes)
[+] AES-128-CBC ciphertext: IV(<hex>) + 16 bytes
[*] Plaintext is all zeros — will trigger empty-slice panic after TrimRight
[+] Built SAML Response (xxx bytes XML, xxx bytes b64)
========================================================
Phase 3: Send payload to /acs
========================================================
[*] POST http://localhost:9999/acs
[*] The server will decrypt our ciphertext, hit the all-zero
plaintext edge case, and panic in DecryptBytes()...
[*] Got HTTP 500 — goroutine panicked but net/http recovered it
========================================================
Phase 4: Verify server status
========================================================
[*] Server is still responding (net/http recovered the goroutine panic)
[*] But the panic stack trace in server logs confirms the vulnerability.
[*] In non-HTTP servers, the process would be dead.
========================================================
VULNERABILITY CONFIRMED
types/encrypted_assertion.go:77 — index out of range [-1]
Stack trace:
types/encrypted_assertion.go:77 (padLength := data[len(data)-1])
decode_response.go:176 (decryptAssertions)
decode_response.go:346 (ValidateEncodedResponse)
========================================================
Server logs (panic stack trace):
http: panic serving 127.0.0.1:xxxxx: runtime error: index out of range [-1]
goroutine XX [running]:
net/http.(*conn).serve.func1()
/usr/local/go/src/net/http/server.go:1898 +0xbe
github.com/russellhaering/gosaml2/types.(*EncryptedAssertion).DecryptBytes(...)
types/encrypted_assertion.go:77 +0x...
github.com/russellhaering/gosaml2.(*SAMLServiceProvider).decryptAssertions.func1(...)
decode_response.go:176 +0x...
github.com/russellhaering/gosaml2.(*SAMLServiceProvider).decryptAssertions(...)
decode_response.go:196 +0x...
github.com/russellhaering/gosaml2.(*SAMLServiceProvider).ValidateEncodedResponse(...)
decode_response.go:346 +0x...
Suggested Fix
Replace the unsafe zero-byte trimming and unchecked index with proper PKCS#7 unpadding and bounds checks:
case MethodAES128CBC, MethodAES256CBC, MethodTripleDESCBC:
if len(data)%k.BlockSize() != 0 {
return nil, fmt.Errorf("ciphertext not multiple of block size")
}
nonce, data := data[:k.BlockSize()], data[k.BlockSize():]
c := cipher.NewCBCDecrypter(k, nonce)
c.CryptBlocks(data, data)
// Validate decrypted data is non-empty
if len(data) == 0 {
return nil, fmt.Errorf("decrypted data is empty")
}
// Proper PKCS#7 unpadding with bounds checks
padLength := int(data[len(data)-1])
if padLength < 1 || padLength > k.BlockSize() || padLength > len(data) {
return nil, fmt.Errorf("invalid padding length: %d", padLength)
}
// Verify all padding bytes are consistent
for i := len(data) - padLength; i < len(data); i++ {
if data[i] != byte(padLength) {
return nil, fmt.Errorf("invalid PKCS#7 padding")
}
}
return data[:len(data)-padLength], nil
Key changes:
1. Remove bytes.TrimRight(data, "\x00") entirely — it corrupts valid PKCS#7-padded data and creates the empty-slice condition.
2. Bounds-check padLength before using it as a slice index.
3. Validate all padding bytes match (proper PKCS#7 verification).
4. Return errors instead of panicking on malformed input.
Severity
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.10.0"
},
"package": {
"ecosystem": "Go",
"name": "github.com/russellhaering/gosaml2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.11.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-18T20:19:11Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\nThe AES-CBC decryption path in `DecryptBytes()` panics on crafted ciphertext whose plaintext is all zero bytes. After decryption, `bytes.TrimRight(data, \"\\x00\")` empties the slice, then `data[len(data)-1]` panics with `index out of range [-1]`. There is no `recover()` in the library. The panic propagates through `ValidateEncodedResponse` and kills the goroutine (or the entire process in non-`net/http` servers). An attacker needs only the SP\u0027s public RSA key (published in SAML metadata) to construct the payload \u2014 no valid signature is required.\n\n## Affected Version\n\nAll versions of `github.com/russellhaering/gosaml2` through latest (`v0.9.0` and HEAD) that support AES-CBC encrypted assertions.\n\n## Vulnerable Code\n\n**`types/encrypted_assertion.go:65-79`** \u2014 `DecryptBytes`, AES-CBC branch:\n\n```go\ncase MethodAES128CBC, MethodAES256CBC, MethodTripleDESCBC:\n if len(data)%k.BlockSize() != 0 {\n return nil, fmt.Errorf(\"encrypted data is not a multiple of the expected CBC block size %d: actual size %d\", k.BlockSize(), len(data))\n }\n nonce, data := data[:k.BlockSize()], data[k.BlockSize():]\n c := cipher.NewCBCDecrypter(k, nonce)\n c.CryptBlocks(data, data)\n\n // Remove zero bytes\n data = bytes.TrimRight(data, \"\\x00\") // \u003c-- empties the slice if plaintext is all zeros\n\n // Calculate index to remove based on padding\n padLength := data[len(data)-1] // \u003c-- PANIC: index out of range [-1]\n lastGoodIndex := len(data) - int(padLength)\n return data[:lastGoodIndex], nil\n```\n\n## Attack Details\n\n| Property | Value |\n|---|---|\n| **Attack Vector** | Network (unauthenticated HTTP POST to ACS endpoint) |\n| **Authentication Required** | None |\n| **Attacker Knowledge** | SP\u0027s public RSA certificate (published in SAML metadata) |\n| **Signature Required** | No \u2014 decryption happens before assertion signature validation |\n| **Payload Size** | Single HTTP POST (~2 KB) |\n| **Repeatability** | Unlimited \u2014 attacker can send the payload repeatedly |\n| **Affected Configurations** | Any SP with `SPKeyStore` configured (encrypted assertion support) |\n| **Trigger Condition** | AES-CBC plaintext that is all `0x00` bytes after decryption |\n\n## Impact\n\n- **Process crash**: In gRPC servers, custom frameworks, CLI tools, and background workers, the unrecovered panic kills the entire OS process immediately.\n- **Goroutine crash**: In `net/http` servers, the built-in per-goroutine recovery catches the panic, returning HTTP 500 and logging the full stack trace. The server survives but the request-handling goroutine is terminated abnormally.\n- **Denial of service**: The attack is unauthenticated and repeatable. A single crafted HTTP request is sufficient. Automated retries can keep the service down indefinitely.\n- **No valid signature needed**: The SAML Response does not need to be signed. On the unsigned-response code path (`decode_response.go:346`), `decryptAssertions()` is called **before** any assertion signature validation.\n\n## Reproduction\n\n### Prerequisites\n\n- Docker (for the vulnerable server)\n- Python 3.8+ with `cryptography` and `requests` packages\n\n### Files\n\n| File | Description |\n|---|---|\n| `server.go` | Minimal SAML SP using gosaml2 \u2014 the victim |\n| `poc.py` | Attacker script \u2014 builds and sends the crafted payload |\n| `Dockerfile` | Multi-stage build for the vulnerable server |\n| `run.sh` | Build and orchestration script |\n\n### Steps\n\n```bash\n# 1. Build the vulnerable server\n./run.sh build\n\n# 2. Start the server\n./run.sh start\n\n# 3. Run the attacker script\npip install cryptography requests\n./run.sh attack\n\n# Or do everything in one command:\n./run.sh all\n```\n\n### Expected Output\n\n**Attacker terminal (`poc.py`):**\n\n```\n ========================================================\n CVE: CBC Padding Panic \u2014 Unauthenticated Process Crash\n Target: gosaml2 (github.com/russellhaering/gosaml2)\n File: types/encrypted_assertion.go:77\n Impact: Remote DoS \u2014 single HTTP request kills process\n ========================================================\n\n[*] Target: http://localhost:9999\n[*] Checking server health...\n[+] Server is alive\n\n========================================================\n Phase 1: Obtain SP public certificate from metadata\n========================================================\n[*] GET http://localhost:9999/metadata\n[+] Retrieved SP certificate (xxx bytes)\n\n========================================================\n Phase 2: Build crafted EncryptedAssertion payload\n========================================================\n[+] Extracted RSA public key (size=2048 bits)\n[*] Generated AES-128 key: \u003chex\u003e\n[+] RSA-OAEP encrypted AES key (256 bytes)\n[+] AES-128-CBC ciphertext: IV(\u003chex\u003e) + 16 bytes\n[*] Plaintext is all zeros \u2014 will trigger empty-slice panic after TrimRight\n[+] Built SAML Response (xxx bytes XML, xxx bytes b64)\n\n========================================================\n Phase 3: Send payload to /acs\n========================================================\n[*] POST http://localhost:9999/acs\n[*] The server will decrypt our ciphertext, hit the all-zero\n plaintext edge case, and panic in DecryptBytes()...\n\n[*] Got HTTP 500 \u2014 goroutine panicked but net/http recovered it\n\n========================================================\n Phase 4: Verify server status\n========================================================\n[*] Server is still responding (net/http recovered the goroutine panic)\n[*] But the panic stack trace in server logs confirms the vulnerability.\n[*] In non-HTTP servers, the process would be dead.\n\n========================================================\n VULNERABILITY CONFIRMED\n types/encrypted_assertion.go:77 \u2014 index out of range [-1]\n\n Stack trace:\n types/encrypted_assertion.go:77 (padLength := data[len(data)-1])\n decode_response.go:176 (decryptAssertions)\n decode_response.go:346 (ValidateEncodedResponse)\n========================================================\n```\n\n**Server logs (panic stack trace):**\n\n```\nhttp: panic serving 127.0.0.1:xxxxx: runtime error: index out of range [-1]\ngoroutine XX [running]:\nnet/http.(*conn).serve.func1()\n /usr/local/go/src/net/http/server.go:1898 +0xbe\ngithub.com/russellhaering/gosaml2/types.(*EncryptedAssertion).DecryptBytes(...)\n types/encrypted_assertion.go:77 +0x...\ngithub.com/russellhaering/gosaml2.(*SAMLServiceProvider).decryptAssertions.func1(...)\n decode_response.go:176 +0x...\ngithub.com/russellhaering/gosaml2.(*SAMLServiceProvider).decryptAssertions(...)\n decode_response.go:196 +0x...\ngithub.com/russellhaering/gosaml2.(*SAMLServiceProvider).ValidateEncodedResponse(...)\n decode_response.go:346 +0x...\n```\n\n## Suggested Fix\n\nReplace the unsafe zero-byte trimming and unchecked index with proper PKCS#7 unpadding and bounds checks:\n\n```go\ncase MethodAES128CBC, MethodAES256CBC, MethodTripleDESCBC:\n if len(data)%k.BlockSize() != 0 {\n return nil, fmt.Errorf(\"ciphertext not multiple of block size\")\n }\n nonce, data := data[:k.BlockSize()], data[k.BlockSize():]\n c := cipher.NewCBCDecrypter(k, nonce)\n c.CryptBlocks(data, data)\n\n // Validate decrypted data is non-empty\n if len(data) == 0 {\n return nil, fmt.Errorf(\"decrypted data is empty\")\n }\n\n // Proper PKCS#7 unpadding with bounds checks\n padLength := int(data[len(data)-1])\n if padLength \u003c 1 || padLength \u003e k.BlockSize() || padLength \u003e len(data) {\n return nil, fmt.Errorf(\"invalid padding length: %d\", padLength)\n }\n\n // Verify all padding bytes are consistent\n for i := len(data) - padLength; i \u003c len(data); i++ {\n if data[i] != byte(padLength) {\n return nil, fmt.Errorf(\"invalid PKCS#7 padding\")\n }\n }\n\n return data[:len(data)-padLength], nil\n```\n\nKey changes:\n1. **Remove `bytes.TrimRight(data, \"\\x00\")`** entirely \u2014 it corrupts valid PKCS#7-padded data and creates the empty-slice condition.\n2. **Bounds-check `padLength`** before using it as a slice index.\n3. **Validate all padding bytes** match (proper PKCS#7 verification).\n4. **Return errors** instead of panicking on malformed input.",
"id": "GHSA-hwqm-qvj9-4jr2",
"modified": "2026-03-18T20:19:11Z",
"published": "2026-03-18T20:19:11Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/russellhaering/gosaml2/security/advisories/GHSA-hwqm-qvj9-4jr2"
},
{
"type": "PACKAGE",
"url": "https://github.com/russellhaering/gosaml2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "gosaml2 CBC Padding Panic \u2014 Unauthenticated Process Crash"
}
GHSA-HX7R-XMR3-78GC
Vulnerability from github – Published: 2023-06-14 09:30 – Updated: 2024-04-04 04:49
VLAI
Details
A CWE-129: Improper Validation of Array Index vulnerability exists that could cause local denial-of-service, and potentially kernel execution when a malicious actor with local user access crafts a script/program using an unpredictable index to an IOCTL call in the Foxboro.sys driver.
Severity
7.0 (High)
{
"affected": [],
"aliases": [
"CVE-2023-2570"
],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-14T08:15:09Z",
"severity": "HIGH"
},
"details": "\n\n\nA CWE-129: Improper Validation of Array Index vulnerability exists that could cause local\ndenial-of-service, and potentially kernel execution when a malicious actor with local user access\ncrafts a script/program using an unpredictable index to an IOCTL call in the Foxboro.sys driver.\n\n\n\n",
"id": "GHSA-hx7r-xmr3-78gc",
"modified": "2024-04-04T04:49:36Z",
"published": "2023-06-14T09:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2570"
},
{
"type": "WEB",
"url": "https://download.schneider-electric.com/files?p_Doc_Ref=SEVD-2023-164-04\u0026p_enDocType=Security+and+Safety+Notice\u0026p_File_Name=SEVD-2023-164-04.pdf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HXXW-VVRC-QRX3
Vulnerability from github – Published: 2024-10-21 18:30 – Updated: 2025-11-04 00:31
VLAI
Details
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix index out of bounds in DCN30 color transformation
This commit addresses a potential index out of bounds issue in the
cm3_helper_translate_curve_to_hw_format function in the DCN30 color
management module. The issue could occur when the index 'i' exceeds the
number of transfer function points (TRANSFER_FUNC_POINTS).
The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error.
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:180 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:181 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:182 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max
Severity
7.8 (High)
{
"affected": [],
"aliases": [
"CVE-2024-49969"
],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-21T18:15:17Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Fix index out of bounds in DCN30 color transformation\n\nThis commit addresses a potential index out of bounds issue in the\n`cm3_helper_translate_curve_to_hw_format` function in the DCN30 color\nmanagement module. The issue could occur when the index \u0027i\u0027 exceeds the\nnumber of transfer function points (TRANSFER_FUNC_POINTS).\n\nThe fix adds a check to ensure \u0027i\u0027 is within bounds before accessing the\ntransfer function points. If \u0027i\u0027 is out of bounds, the function returns\nfalse to indicate an error.\n\ndrivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:180 cm3_helper_translate_curve_to_hw_format() error: buffer overflow \u0027output_tf-\u003etf_pts.red\u0027 1025 \u003c= s32max\ndrivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:181 cm3_helper_translate_curve_to_hw_format() error: buffer overflow \u0027output_tf-\u003etf_pts.green\u0027 1025 \u003c= s32max\ndrivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:182 cm3_helper_translate_curve_to_hw_format() error: buffer overflow \u0027output_tf-\u003etf_pts.blue\u0027 1025 \u003c= s32max",
"id": "GHSA-hxxw-vvrc-qrx3",
"modified": "2025-11-04T00:31:43Z",
"published": "2024-10-21T18:30:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49969"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0f1e222a4b41d77c442901d166fbdca967af0d86"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/578422ddae3d13362b64e77ef9bab98780641631"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7ab69af56a23859b647dee69fa1052c689343621"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/929506d5671419cffd8d01e9a7f5eae53682a838"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b9d8b94ec7e67f0cae228c054f77b73967c389a3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c13f9c62015c56a938304cef6d507227ea3e0039"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d81873f9e715b72d4f8d391c8eb243946f784dfc"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-J3G9-2F89-WH5P
Vulnerability from github – Published: 2023-03-10 21:30 – Updated: 2023-03-15 21:30
VLAI
Details
Memory corruption due to improper validation of array index in Multi-mode call processor.
Severity
9.8 (Critical)
{
"affected": [],
"aliases": [
"CVE-2022-33256"
],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-03-10T21:15:00Z",
"severity": "CRITICAL"
},
"details": "Memory corruption due to improper validation of array index in Multi-mode call processor.",
"id": "GHSA-j3g9-2f89-wh5p",
"modified": "2023-03-15T21:30:26Z",
"published": "2023-03-10T21:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-33256"
},
{
"type": "WEB",
"url": "https://www.qualcomm.com/company/product-security/bulletins/march-2023-bulletin"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-J45W-P973-WJXH
Vulnerability from github – Published: 2022-05-14 01:57 – Updated: 2022-05-14 01:57
VLAI
Details
In Snapdragon (Automobile, Mobile, Wear) in version MDM9206, MDM9607, MDM9635M, MDM9640, MDM9645, MDM9650, MDM9655, MSM8909W, MSM8996AU, SD 210/SD 212/SD 205, SD 425, SD 427, SD 430, SD 435, SD 450, SD 625, SD 650/52, SD 810, SD 820, SD 820A, SD 835, SD 845, SD 850, SDA660, SDM429, SDM439, SDM630, SDM632, SDM636, SDM660, SDM710, SDX20, Snapdragon_High_Med_2016, a potential buffer overflow exists when parsing TFTP options.
Severity
7.8 (High)
{
"affected": [],
"aliases": [
"CVE-2018-11269"
],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-09-20T13:29:00Z",
"severity": "HIGH"
},
"details": "In Snapdragon (Automobile, Mobile, Wear) in version MDM9206, MDM9607, MDM9635M, MDM9640, MDM9645, MDM9650, MDM9655, MSM8909W, MSM8996AU, SD 210/SD 212/SD 205, SD 425, SD 427, SD 430, SD 435, SD 450, SD 625, SD 650/52, SD 810, SD 820, SD 820A, SD 835, SD 845, SD 850, SDA660, SDM429, SDM439, SDM630, SDM632, SDM636, SDM660, SDM710, SDX20, Snapdragon_High_Med_2016, a potential buffer overflow exists when parsing TFTP options.",
"id": "GHSA-j45w-p973-wjxh",
"modified": "2022-05-14T01:57:02Z",
"published": "2022-05-14T01:57:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-11269"
},
{
"type": "WEB",
"url": "https://www.qualcomm.com/company/product-security/bulletins"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/105838"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-J4QF-CXM7-87P2
Vulnerability from github – Published: 2022-03-17 00:00 – Updated: 2022-03-23 00:00
VLAI
Details
In drivers/usb/gadget/udc/udc-xilinx.c in the Linux kernel before 5.16.12, the endpoint index is not validated and might be manipulated by the host for out-of-array access.
Severity
8.8 (High)
{
"affected": [],
"aliases": [
"CVE-2022-27223"
],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-03-16T00:15:00Z",
"severity": "HIGH"
},
"details": "In drivers/usb/gadget/udc/udc-xilinx.c in the Linux kernel before 5.16.12, the endpoint index is not validated and might be manipulated by the host for out-of-array access.",
"id": "GHSA-j4qf-cxm7-87p2",
"modified": "2022-03-23T00:00:35Z",
"published": "2022-03-17T00:00:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-27223"
},
{
"type": "WEB",
"url": "https://github.com/torvalds/linux/commit/7f14c7227f342d9932f9b918893c8814f86d2a0d"
},
{
"type": "WEB",
"url": "https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.12"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20220419-0001"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-J4RG-H6CW-QR4Q
Vulnerability from github – Published: 2022-05-24 17:32 – Updated: 2022-05-24 17:32
VLAI
Details
u'Array index underflow issue in adsp driver due to improper check of channel id before used as array index.' in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice & Music, Snapdragon Wearables, Snapdragon Wired Infrastructure and Networking in Agatti, APQ8009, APQ8017, APQ8053, APQ8096AU, APQ8098, Bitra, IPQ4019, IPQ5018, IPQ6018, IPQ8064, IPQ8074, Kamorta, MDM9607, MDM9640, MDM9650, MSM8905, MSM8909W, MSM8953, MSM8996AU, QCA6390, QCA9531, QCM2150, QCS404, QCS405, QCS605, SA415M, SA515M, SA6155P, SA8155P, Saipan, SC8180X, SDA660, SDA845, SDM429, SDM429W, SDM630, SDM632, SDM636, SDM660, SDM670, SDM710, SDM845, SDX20, SDX24, SDX55, SM6150, SM8150, SM8250, SXR1130, SXR2130
{
"affected": [],
"aliases": [
"CVE-2020-11174"
],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-11-02T07:15:00Z",
"severity": "HIGH"
},
"details": "u\u0027Array index underflow issue in adsp driver due to improper check of channel id before used as array index.\u0027 in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice \u0026 Music, Snapdragon Wearables, Snapdragon Wired Infrastructure and Networking in Agatti, APQ8009, APQ8017, APQ8053, APQ8096AU, APQ8098, Bitra, IPQ4019, IPQ5018, IPQ6018, IPQ8064, IPQ8074, Kamorta, MDM9607, MDM9640, MDM9650, MSM8905, MSM8909W, MSM8953, MSM8996AU, QCA6390, QCA9531, QCM2150, QCS404, QCS405, QCS605, SA415M, SA515M, SA6155P, SA8155P, Saipan, SC8180X, SDA660, SDA845, SDM429, SDM429W, SDM630, SDM632, SDM636, SDM660, SDM670, SDM710, SDM845, SDX20, SDX24, SDX55, SM6150, SM8150, SM8250, SXR1130, SXR2130",
"id": "GHSA-j4rg-h6cw-qr4q",
"modified": "2022-05-24T17:32:50Z",
"published": "2022-05-24T17:32:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-11174"
},
{
"type": "WEB",
"url": "https://www.qualcomm.com/company/product-security/bulletins/october-2020-bulletin"
},
{
"type": "WEB",
"url": "https://www.qualcomm.com/company/product-security/bulletins/october-2020-security-bulletin"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-JG3V-6RVM-6P3V
Vulnerability from github – Published: 2024-11-04 12:32 – Updated: 2024-11-04 12:32
VLAI
Details
Memory corruption when the user application modifies the same shared memory asynchronously when kernel is accessing it.
Severity
6.7 (Medium)
{
"affected": [],
"aliases": [
"CVE-2024-33032"
],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-04T10:15:05Z",
"severity": "MODERATE"
},
"details": "Memory corruption when the user application modifies the same shared memory asynchronously when kernel is accessing it.",
"id": "GHSA-jg3v-6rvm-6p3v",
"modified": "2024-11-04T12:32:56Z",
"published": "2024-11-04T12:32:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-33032"
},
{
"type": "WEB",
"url": "https://docs.qualcomm.com/product/publicresources/securitybulletin/november-2024-bulletin.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-JGH8-6HMW-5F93
Vulnerability from github – Published: 2025-03-17 18:31 – Updated: 2025-03-17 18:31
VLAI
Details
In the Linux kernel, the following vulnerability has been resolved:
media: pvrusb2: fix array-index-out-of-bounds in pvr2_i2c_core_init
Syzbot reported that -1 is used as array index. The problem was in missing validation check.
hdw->unit_number is initialized with -1 and then if init table walk fails this value remains unchanged. Since code blindly uses this member for array indexing adding sanity check is the easiest fix for that.
hdw->workpoll initialization moved upper to prevent warning in __flush_work.
Severity
7.8 (High)
{
"affected": [],
"aliases": [
"CVE-2022-49478"
],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:24Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: pvrusb2: fix array-index-out-of-bounds in pvr2_i2c_core_init\n\nSyzbot reported that -1 is used as array index. The problem was in\nmissing validation check.\n\nhdw-\u003eunit_number is initialized with -1 and then if init table walk fails\nthis value remains unchanged. Since code blindly uses this member for\narray indexing adding sanity check is the easiest fix for that.\n\nhdw-\u003eworkpoll initialization moved upper to prevent warning in\n__flush_work.",
"id": "GHSA-jgh8-6hmw-5f93",
"modified": "2025-03-17T18:31:50Z",
"published": "2025-03-17T18:31:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49478"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1310fc3538dcc375a2f46ef0a438512c2ca32827"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/24e807541e4a9263ed928e6ae3498de3ad43bd1e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2e004fe914b243db41fa96f9e583385f360ea58e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3309c2c574e13b21b44729f5bdbf21f60189b79a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4351bfe36aba9fa7dc9d68d498d25d41a0f45e67"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/471bec68457aaf981add77b4f590d65dd7da1059"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a3304766d9384886e6d3092c776273526947a2e9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a3660e06675bccec4bf149c7229ea1d491ba10d7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f99a8b1ec0eddc2931aeaa4f490277a15b39f511"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-JGJJ-VMW4-3G37
Vulnerability from github – Published: 2024-04-03 18:30 – Updated: 2024-11-04 21:30
VLAI
Details
In the Linux kernel, the following vulnerability has been resolved:
md: Don't ignore suspended array in md_check_recovery()
mddev_suspend() never stop sync_thread, hence it doesn't make sense to ignore suspended array in md_check_recovery(), which might cause sync_thread can't be unregistered.
After commit f52f5c71f3d4 ("md: fix stopping sync thread"), following hang can be triggered by test shell/integrity-caching.sh:
1) suspend the array: raid_postsuspend mddev_suspend
2) stop the array: raid_dtr md_stop __md_stop_writes stop_sync_thread set_bit(MD_RECOVERY_INTR, &mddev->recovery); md_wakeup_thread_directly(mddev->sync_thread); wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery))
3) sync thread done: md_do_sync set_bit(MD_RECOVERY_DONE, &mddev->recovery); md_wakeup_thread(mddev->thread);
4) daemon thread can't unregister sync thread: md_check_recovery if (mddev->suspended) return; -> return directly md_read_sync_thread clear_bit(MD_RECOVERY_RUNNING, &mddev->recovery); -> MD_RECOVERY_RUNNING can't be cleared, hence step 2 hang;
This problem is not just related to dm-raid, fix it by ignoring suspended array in md_check_recovery(). And follow up patches will improve dm-raid better to frozen sync thread during suspend.
Severity
5.5 (Medium)
{
"affected": [],
"aliases": [
"CVE-2024-26758"
],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-03T17:15:52Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmd: Don\u0027t ignore suspended array in md_check_recovery()\n\nmddev_suspend() never stop sync_thread, hence it doesn\u0027t make sense to\nignore suspended array in md_check_recovery(), which might cause\nsync_thread can\u0027t be unregistered.\n\nAfter commit f52f5c71f3d4 (\"md: fix stopping sync thread\"), following\nhang can be triggered by test shell/integrity-caching.sh:\n\n1) suspend the array:\nraid_postsuspend\n mddev_suspend\n\n2) stop the array:\nraid_dtr\n md_stop\n __md_stop_writes\n stop_sync_thread\n set_bit(MD_RECOVERY_INTR, \u0026mddev-\u003erecovery);\n md_wakeup_thread_directly(mddev-\u003esync_thread);\n wait_event(..., !test_bit(MD_RECOVERY_RUNNING, \u0026mddev-\u003erecovery))\n\n3) sync thread done:\nmd_do_sync\n set_bit(MD_RECOVERY_DONE, \u0026mddev-\u003erecovery);\n md_wakeup_thread(mddev-\u003ethread);\n\n4) daemon thread can\u0027t unregister sync thread:\nmd_check_recovery\n if (mddev-\u003esuspended)\n return; -\u003e return directly\n md_read_sync_thread\n clear_bit(MD_RECOVERY_RUNNING, \u0026mddev-\u003erecovery);\n -\u003e MD_RECOVERY_RUNNING can\u0027t be cleared, hence step 2 hang;\n\nThis problem is not just related to dm-raid, fix it by ignoring\nsuspended array in md_check_recovery(). And follow up patches will\nimprove dm-raid better to frozen sync thread during suspend.",
"id": "GHSA-jgjj-vmw4-3g37",
"modified": "2024-11-04T21:30:26Z",
"published": "2024-04-03T18:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26758"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1baae052cccd08daf9a9d64c3f959d8cdb689757"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a55f0d6179a19c6b982e2dc344d58c98647a3be0"
}
],
"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"
}
]
}
Mitigation MIT-7
Architecture and Design
Strategy: Input Validation
Use an input validation framework such as Struts or the OWASP ESAPI Validation API. Note that using a framework does not automatically address all input validation problems; be mindful of weaknesses that could arise from misusing the framework itself (CWE-1173).
Mitigation MIT-15
Architecture and Design
- For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
- Even though client-side checks provide minimal benefits with respect to server-side security, they are still useful. First, they can support intrusion detection. If the server receives input that should have been rejected by the client, then it may be an indication of an attack. Second, client-side error-checking can provide helpful feedback to the user about the expectations for valid input. Third, there may be a reduction in server-side processing time for accidental input errors, although this is typically a small savings.
Mitigation MIT-3
Requirements
Strategy: Language Selection
- Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, Ada allows the programmer to constrain the values of a variable and languages such as Java and Ruby will allow the programmer to handle exceptions when an out-of-bounds index is accessed.
Mitigation MIT-11
Operation
Build and Compilation
Strategy: Environment Hardening
- Run or compile the software using features or extensions that randomly arrange the positions of a program's executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code.
- Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64]. Imported modules may be similarly realigned if their default memory addresses conflict with other modules, in a process known as "rebasing" (for Windows) and "prelinking" (for Linux) [REF-1332] using randomly generated addresses. ASLR for libraries cannot be used in conjunction with prelink since it would require relocating the libraries at run-time, defeating the whole purpose of prelinking.
- For more information on these techniques see D3-SAOR (Segment Address Offset Randomization) from D3FEND [REF-1335].
Mitigation MIT-12
Operation
Strategy: Environment Hardening
- Use a CPU and operating system that offers Data Execution Protection (using hardware NX or XD bits) or the equivalent techniques that simulate this feature in software, such as PaX [REF-60] [REF-61]. These techniques ensure that any instruction executed is exclusively at a memory address that is part of the code segment.
- For more information on these techniques see D3-PSEP (Process Segment Execution Prevention) from D3FEND [REF-1336].
Mitigation MIT-5
Implementation
Strategy: Input Validation
- Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
- When accessing a user-controlled array index, use a stringent range of values that are within the target array. Make sure that you do not allow negative values to be used. That is, verify the minimum as well as the maximum of the range of acceptable values.
Mitigation MIT-35
Implementation
Be especially careful to validate all input when invoking code that crosses language boundaries, such as from an interpreted language to native code. This could create an unexpected interaction between the language boundaries. Ensure that you are not violating any of the expectations of the language with which you are interfacing. For example, even though Java may not be susceptible to buffer overflows, providing a large argument in a call to native code might trigger an overflow.
Mitigation MIT-17
Architecture and Design
Operation
Strategy: Environment Hardening
Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
Mitigation MIT-22
Architecture and Design
Operation
Strategy: Sandbox or Jail
- Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.
- OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.
- This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.
- Be careful to avoid CWE-243 and other weaknesses related to jails.
CAPEC-100: Overflow Buffers
Buffer Overflow attacks target improper or missing bounds checking on buffer operations, typically triggered by input injected by an adversary. As a consequence, an adversary is able to write past the boundaries of allocated buffer regions in memory, causing a program crash or potentially redirection of execution as per the adversaries' choice.