CWE-125
AllowedOut-of-bounds Read
Abstraction: Base · Status: Draft
The product reads data past the end, or before the beginning, of the intended buffer.
11291 vulnerabilities reference this CWE, most recent first.
GHSA-HPQ4-FC7M-PX2F
Vulnerability from github – Published: 2024-03-12 18:31 – Updated: 2024-03-12 18:31Windows Kernel Information Disclosure Vulnerability
{
"affected": [],
"aliases": [
"CVE-2024-26174"
],
"database_specific": {
"cwe_ids": [
"CWE-125"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-12T17:15:56Z",
"severity": "MODERATE"
},
"details": "Windows Kernel Information Disclosure Vulnerability",
"id": "GHSA-hpq4-fc7m-px2f",
"modified": "2024-03-12T18:31:14Z",
"published": "2024-03-12T18:31:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26174"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-26174"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-HPQH-2WQX-7QP5
Vulnerability from github – Published: 2021-08-25 21:01 – Updated: 2024-11-19 19:18There is a bug in 0.73.0 of the Cranelift x64 backend that can create a scenario that could result in a potential sandbox escape in a WebAssembly module. Users of versions 0.73.0 of Cranelift should upgrade to either 0.73.1 or 0.74 to remediate this vulnerability. Users of Cranelift prior to 0.73.0 should update to 0.73.1 or 0.74 if they were not using the old default backend.
Description
This bug was introduced in the new backend on 2020-09-08 and first included in a release on 2020-09-30, but the new backend was not the default prior to 0.73.0. The recently-released version 0.73.0 with default settings, and prior versions with an explicit build flag to select the new backend, are vulnerable. The bug in question performs a sign-extend instead of a zero-extend on a value loaded from the stack, under a specific set of circumstances. If those circumstances occur, the bug could allow access to memory addresses up to 2GiB before the start of the heap allocated for the WebAssembly module.
If the heap bound is larger than 2GiB, then it would be possible to read memory from a computable range dependent on the size of the heap's bound.
The impact of this bug is highly dependent on heap implementation; specifically: * if the heap has bounds checks, and * does not rely exclusively on guard pages, and * the heap bound is 2GiB or smaller
then this bug cannot be used to reach memory from another WebAssembly module heap.
The impact of the vulnerability is mitigated if there is no memory mapped in the range accessible using this bug, for example, if there is a 2 GiB guard region before the WebAssembly module heap.
The bug in question performs a sign-extend instead of a zero-extend on a value loaded from the stack when the register allocator reloads a spilled integer value narrower than 64 bits. This interacts poorly with another optimization: the instruction selector elides a 32-to-64-bit zero-extend operator when we know that an instruction producing a 32-bit value actually zeros the upper 32 bits of its destination register. Hence, we rely on these zeroed bits, but the type of the value is still i32, and the spill/reload reconstitutes those bits as the sign extension of the i32’s MSB.
The issue would thus occur when: * An i32 value is greater than or equal to 0x8000_0000; * The value is spilled and reloaded by the register allocator due to high register pressure in the program between the value’s definition and its use; * The value is produced by an instruction that we know to be "special" in that it zeroes the upper 32 bits of its destination: add, sub, mul, and, or; * The value is then zero-extended to 64 bits; * The resulting 64-bit value is used.
Under these circumstances there is a potential sandbox escape when the i32 value is a pointer. The usual code emitted for heap accesses zero-extends the WebAssembly heap address, adds it to a 64-bit heap base, and accesses the resulting address. If the zero-extend becomes a sign-extend, the module could reach backward and access memory up to 2GiB before the start of its heap.
This bug was identified by developers at Fastly following a report from Javier Cabrera Arteaga, KTH Royal Institute of Technology, with support from project Trustful of Stiftelsen för Strategisk Forskning. In addition to supporting the analysis and remediation of this vulnerability, Fastly will publish a related Fastly Security Advisory at https://www.fastly.com/security-advisories.
In addition to assessing the nature of the code generation bug in Cranelift, we have also determined that under specific circumstances, both Lucet and Wasmtime using this version of Cranelift may be exploitable.
General Impact to Lucet
Lucet inherits the heap address computation and bounds-checks of Cranelift, which it uses as its backend code generator. Of particular importance specifically is the address-space layout used by Lucet. In the default configuration for Lucet, only a single module is running, and therefore it is not possible to access memory from another module.
By default, the open source implementation of Lucet uses a maximum heap size of 4 GiB, and an instance slot size of 8 GiB, when invoking an instance from the lucet-wasi command-line tool. These settings are within the range of vulnerability described above, but only a single instance is running, so there is no other instance to read. When embedding the runtime (for example, in a long-running daemon), the default for the heap size as described in the source is 1MB; with this setting, the runtime is not vulnerable.
Lucet allocates its WebAssembly module instances into "instance slots", which are contiguous zones of virtual address space that contain the VM context at the bottom, the WebAssembly heap in the next page after that, a guard region in the middle, and other data at the top: the stack and the globals.
If the instance slot size is less than (max heap) + 2GiB, then the lowest accessible address using the bug will overlap with the prior instance’s heap. If the size of VM context + stack + globals is greater than (4GiB - heap limit), then the highest accessible address using the bug will overlap with this critical data. If neither of these conditions are true, the bug should only result in an access to the prior instance’s guard region.
Generally, if the limit is between 2GiB and 4GiB - ~1MB (depending on stack/global size) and the instance slot size is less than 6GiB, the configuration is vulnerable. If the limit is greater than 4GiB - ~1MB, the configuration is vulnerable regardless of instance slot size. Otherwise, the configuration is not vulnerable.
General Impact on Wasmtime
In Wasmtime, the same Cranelift heap address computations and heap types are used as above. The memory layout, however, is slightly different, with different outcomes: * With the mmap implementation impact is mitigated probabilistically if ASLR is enabled. * With the pooling allocator, the vulnerability only exists if a memory reservation size lower than the default of 6GB is used.
With the default mmap-based instance memory implementation, Wasmtime uses mmap() to allocate a block of memory large enough for the heap and guard region, as specified in its configuration. If the underlying OS implements ASLR (modern Linux, macOS and Windows do) then this address will be randomized, and the region below it will (probabilistically) be free. Hence, the bug is mitigated probabilistically in the default configuration if ASLR is enabled.
If using the pooling allocator, the vulnerability exists if instance memory size (memory_reservation_size in InstanceLimit) is strictly less than 6GiB (4 GiB + 2 GiB of guard pages). The default is 6GiB, so the vulnerability is masked in the default pooling allocator configuration.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "cranelift-codegen"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.73.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "wasmtime"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.27.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-32629"
],
"database_specific": {
"cwe_ids": [
"CWE-125",
"CWE-788"
],
"github_reviewed": true,
"github_reviewed_at": "2021-05-25T20:51:32Z",
"nvd_published_at": "2021-05-24T16:15:00Z",
"severity": "HIGH"
},
"details": "There is a bug in 0.73.0 of the Cranelift x64 backend that can create a scenario that could result in a potential sandbox escape in a WebAssembly module. Users of versions 0.73.0 of Cranelift should upgrade to either 0.73.1 or 0.74 to remediate this vulnerability. Users of Cranelift prior to 0.73.0 should update to 0.73.1 or 0.74 if they were not using the old default backend.\n\n### Description\n\nThis bug was introduced in the new backend on 2020-09-08 and first included in a release on 2020-09-30, but the new backend was not the default prior to 0.73.0. The recently-released version 0.73.0 with default settings, and prior versions with an explicit build flag to select the new backend, are vulnerable. The bug in question performs a sign-extend instead of a zero-extend on a value loaded from the stack, under a specific set of circumstances. If those circumstances occur, the bug could allow access to memory addresses up to 2GiB before the start of the heap allocated for the WebAssembly module.\n\nIf the heap bound is larger than 2GiB, then it would be possible to read memory from a computable range dependent on the size of the heap\u0027s bound. \n\nThe impact of this bug is highly dependent on heap implementation; specifically:\n* if the heap has bounds checks, and\n* does not rely exclusively on guard pages, and \n* the heap bound is 2GiB or smaller \n\nthen this bug cannot be used to reach memory from another WebAssembly module heap.\n\nThe impact of the vulnerability is mitigated if there is no memory mapped in the range accessible using this bug, for example, if there is a 2 GiB guard region before the WebAssembly module heap.\n\nThe bug in question performs a sign-extend instead of a zero-extend on a value loaded from the stack when the register allocator reloads a spilled integer value narrower than 64 bits. This interacts poorly with another optimization: the instruction selector elides a 32-to-64-bit zero-extend operator when we know that an instruction producing a 32-bit value actually zeros the upper 32 bits of its destination register. Hence, we rely on these zeroed bits, but the type of the value is still i32, and the spill/reload reconstitutes those bits as the sign extension of the i32\u2019s MSB.\n\nThe issue would thus occur when:\n* An i32 value is greater than or equal to 0x8000_0000;\n* The value is spilled and reloaded by the register allocator due to high register pressure in the program between the value\u2019s definition and its use;\n* The value is produced by an instruction that we know to be \"special\" in that it zeroes the upper 32 bits of its destination: add, sub, mul, and, or;\n* The value is then zero-extended to 64 bits;\n* The resulting 64-bit value is used.\n\nUnder these circumstances there is a potential sandbox escape when the i32 value is a pointer. The usual code emitted for heap accesses zero-extends the WebAssembly heap address, adds it to a 64-bit heap base, and accesses the resulting address. If the zero-extend becomes a sign-extend, the module could reach backward and access memory up to 2GiB before the start of its heap.\n\nThis bug was identified by developers at Fastly following a report from Javier Cabrera Arteaga, KTH Royal Institute of Technology, with support from project Trustful of Stiftelsen f\u00f6r Strategisk Forskning. In addition to supporting the analysis and remediation of this vulnerability, Fastly will publish a related Fastly Security Advisory at [https://www.fastly.com/security-advisories](https://www.fastly.com/security-advisories).\n\nIn addition to assessing the nature of the code generation bug in Cranelift, we have also determined that under specific circumstances, both Lucet and Wasmtime using this version of Cranelift may be exploitable.\n\n### General Impact to Lucet\n\nLucet inherits the heap address computation and bounds-checks of Cranelift, which it uses as its backend code generator. Of particular importance specifically is the address-space layout used by Lucet. In the default configuration for Lucet, only a single module is running, and therefore it is not possible to access memory from another module.\n\nBy default, the open source implementation of Lucet uses a maximum heap size of 4 GiB, and an instance slot size of 8 GiB, when invoking an instance from the lucet-wasi command-line tool. These settings are within the range of vulnerability described above, but only a single instance is running, so there is no other instance to read. When embedding the runtime (for example, in a long-running daemon), the default for the heap size as described in the source is 1MB; with this setting, the runtime is not vulnerable.\n\nLucet allocates its WebAssembly module instances into \"instance slots\", which are contiguous zones of virtual address space that contain the VM context at the bottom, the WebAssembly heap in the next page after that, a guard region in the middle, and other data at the top: the stack and the globals.\n\nIf the instance slot size is less than (max heap) + 2GiB, then the lowest accessible address using the bug will overlap with the prior instance\u2019s heap. If the size of VM context + stack + globals is greater than (4GiB - heap limit), then the highest accessible address using the bug will overlap with this critical data. If neither of these conditions are true, the bug should only result in an access to the prior instance\u2019s guard region.\n\nGenerally, if the limit is between 2GiB and 4GiB - ~1MB (depending on stack/global size) and the instance slot size is less than 6GiB, the configuration is vulnerable. If the limit is greater than 4GiB - ~1MB, the configuration is vulnerable regardless of instance slot size. Otherwise, the configuration is not vulnerable.\n\n### General Impact on Wasmtime\n\nIn Wasmtime, the same Cranelift heap address computations and heap types are used as above. The memory layout, however, is slightly different, with different outcomes:\n* With the mmap implementation impact is mitigated probabilistically if ASLR is enabled.\n* With the pooling allocator, the vulnerability only exists if a memory reservation size lower than the default of 6GB is used.\n\nWith the default mmap-based instance memory implementation, Wasmtime uses mmap() to allocate a block of memory large enough for the heap and guard region, as specified in its configuration. If the underlying OS implements ASLR (modern Linux, macOS and Windows do) then this address will be randomized, and the region below it will (probabilistically) be free. Hence, the bug is mitigated probabilistically in the default configuration if ASLR is enabled.\n\nIf using the pooling allocator, the vulnerability exists if instance memory size (`memory_reservation_size` in InstanceLimit) is strictly less than 6GiB (4 GiB + 2 GiB of guard pages). The default is 6GiB, so the vulnerability is masked in the default pooling allocator configuration.\n",
"id": "GHSA-hpqh-2wqx-7qp5",
"modified": "2024-11-19T19:18:55Z",
"published": "2021-08-25T21:01:55Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-hpqh-2wqx-7qp5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32629"
},
{
"type": "WEB",
"url": "https://github.com/bytecodealliance/wasmtime/commit/95559c01aaa7c061088a433040f31e8291fb09d0"
},
{
"type": "WEB",
"url": "https://crates.io/crates/cranelift-codegen"
},
{
"type": "WEB",
"url": "https://github.com/RustSec/advisory-db/blob/main/crates/cranelift-codegen/RUSTSEC-2021-0067.md"
},
{
"type": "PACKAGE",
"url": "https://github.com/bytecodealliance/wasmtime/tree/main/cranelift"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/wasmtime/PYSEC-2021-87.yaml"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2021-0067.html"
},
{
"type": "WEB",
"url": "https://www.fastly.com/security-advisories/memory-access-due-to-code-generation-flaw-in-cranelift-module"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Memory access due to code generation flaw in Cranelift module"
}
GHSA-HPQJ-75W6-HX26
Vulnerability from github – Published: 2022-05-24 16:54 – Updated: 2022-05-24 16:54Adobe Acrobat and Reader versions , 2019.012.20035 and earlier, 2019.012.20035 and earlier, 2017.011.30142 and earlier, 2017.011.30143 and earlier, 2017.011.30142 and earlier, 2015.006.30497 and earlier, and 2015.006.30498 and earlier have an out-of-bounds read vulnerability. Successful exploitation could lead to information disclosure .
{
"affected": [],
"aliases": [
"CVE-2019-8032"
],
"database_specific": {
"cwe_ids": [
"CWE-125"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-08-20T20:15:00Z",
"severity": "HIGH"
},
"details": "Adobe Acrobat and Reader versions , 2019.012.20035 and earlier, 2019.012.20035 and earlier, 2017.011.30142 and earlier, 2017.011.30143 and earlier, 2017.011.30142 and earlier, 2015.006.30497 and earlier, and 2015.006.30498 and earlier have an out-of-bounds read vulnerability. Successful exploitation could lead to information disclosure .",
"id": "GHSA-hpqj-75w6-hx26",
"modified": "2022-05-24T16:54:13Z",
"published": "2022-05-24T16:54:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-8032"
},
{
"type": "WEB",
"url": "https://helpx.adobe.com/security/products/acrobat/apsb19-41.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-HPV4-7P9C-MVFR
Vulnerability from github – Published: 2021-08-25 14:43 – Updated: 2024-11-13 17:26Impact
The implementation for tf.raw_ops.FractionalAvgPoolGrad can be tricked into accessing data outside of bounds of heap allocated buffers:
import tensorflow as tf
tf.raw_ops.FractionalAvgPoolGrad(
orig_input_tensor_shape=[0,1,2,3],
out_backprop = np.array([[[[541],[541]],[[541],[541]]]]),
row_pooling_sequence=[0, 0, 0, 0, 0],
col_pooling_sequence=[-2, 0, 0, 2, 0],
overlapping=True)
The implementation does not validate that the input tensor is non-empty. Thus, code constructs an empty EigenDoubleMatrixMap and then accesses this buffer with indices that are outside of the empty area.
Patches
We have patched the issue in GitHub commit 0f931751fb20f565c4e94aa6df58d54a003cdb30.
The fix will be included in TensorFlow 2.6.0. We will also cherrypick this commit on TensorFlow 2.5.1, TensorFlow 2.4.3, and TensorFlow 2.3.4, 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 members of the Aivul Team from Qihoo 360.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.3.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow"
},
"ranges": [
{
"events": [
{
"introduced": "2.4.0"
},
{
"fixed": "2.4.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow"
},
"ranges": [
{
"events": [
{
"introduced": "2.5.0"
},
{
"fixed": "2.5.1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"2.5.0"
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-cpu"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.3.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-cpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.4.0"
},
{
"fixed": "2.4.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-cpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.5.0"
},
{
"fixed": "2.5.1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"2.5.0"
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-gpu"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.3.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-gpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.4.0"
},
{
"fixed": "2.4.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-gpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.5.0"
},
{
"fixed": "2.5.1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"2.5.0"
]
}
],
"aliases": [
"CVE-2021-37651"
],
"database_specific": {
"cwe_ids": [
"CWE-125",
"CWE-787"
],
"github_reviewed": true,
"github_reviewed_at": "2021-08-23T23:20:28Z",
"nvd_published_at": "2021-08-12T21:15:00Z",
"severity": "HIGH"
},
"details": "### Impact\nThe implementation for `tf.raw_ops.FractionalAvgPoolGrad` can be tricked into accessing data outside of bounds of heap allocated buffers:\n\n```python\nimport tensorflow as tf\n\ntf.raw_ops.FractionalAvgPoolGrad(\n orig_input_tensor_shape=[0,1,2,3],\n out_backprop = np.array([[[[541],[541]],[[541],[541]]]]),\n row_pooling_sequence=[0, 0, 0, 0, 0],\n col_pooling_sequence=[-2, 0, 0, 2, 0],\n overlapping=True)\n```\n\nThe [implementation](https://github.com/tensorflow/tensorflow/blob/f24faa153ad31a4b51578f8181d3aaab77a1ddeb/tensorflow/core/kernels/fractional_avg_pool_op.cc#L205) does not validate that the input tensor is non-empty. Thus, code constructs an empty `EigenDoubleMatrixMap` and then accesses this buffer with indices that are outside of the empty area.\n\n### Patches\nWe have patched the issue in GitHub commit [0f931751fb20f565c4e94aa6df58d54a003cdb30](https://github.com/tensorflow/tensorflow/commit/0f931751fb20f565c4e94aa6df58d54a003cdb30).\n\nThe fix will be included in TensorFlow 2.6.0. We will also cherrypick this commit on TensorFlow 2.5.1, TensorFlow 2.4.3, and TensorFlow 2.3.4, as these are also affected and still in supported range.\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### Attribution\nThis vulnerability has been reported by members of the Aivul Team from Qihoo 360.",
"id": "GHSA-hpv4-7p9c-mvfr",
"modified": "2024-11-13T17:26:29Z",
"published": "2021-08-25T14:43:21Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/tensorflow/tensorflow/security/advisories/GHSA-hpv4-7p9c-mvfr"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-37651"
},
{
"type": "WEB",
"url": "https://github.com/tensorflow/tensorflow/commit/0f931751fb20f565c4e94aa6df58d54a003cdb30"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow-cpu/PYSEC-2021-564.yaml"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow-gpu/PYSEC-2021-762.yaml"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow/PYSEC-2021-273.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/tensorflow/tensorflow"
}
],
"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:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Heap buffer overflow in `FractionalAvgPoolGrad`"
}
GHSA-HPV5-W2GM-C9R5
Vulnerability from github – Published: 2022-05-24 19:05 – Updated: 2022-05-24 19:05In accessAudioHalPidscpp of TimeCheck.cpp, there is a possible out of bounds read due to a missing bounds check. This could lead to local information disclosure with System execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-11Android ID: A-175894436
{
"affected": [],
"aliases": [
"CVE-2021-0566"
],
"database_specific": {
"cwe_ids": [
"CWE-125"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-06-22T11:15:00Z",
"severity": "MODERATE"
},
"details": "In accessAudioHalPidscpp of TimeCheck.cpp, there is a possible out of bounds read due to a missing bounds check. This could lead to local information disclosure with System execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-11Android ID: A-175894436",
"id": "GHSA-hpv5-w2gm-c9r5",
"modified": "2022-05-24T19:05:56Z",
"published": "2022-05-24T19:05:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-0566"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/pixel/2021-06-01"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-HPV6-625J-5G5J
Vulnerability from github – Published: 2024-11-20 18:32 – Updated: 2024-11-20 21:30In bta_dm_remove_sec_dev_entry of bta_dm_act.cc, there is a possible out of bounds read due to a use after free. This could lead to remote information disclosure over bluetooth with no additional execution privileges needed. User interaction is not needed for exploitation.
{
"affected": [],
"aliases": [
"CVE-2018-9483"
],
"database_specific": {
"cwe_ids": [
"CWE-125",
"CWE-416"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-20T18:15:20Z",
"severity": "MODERATE"
},
"details": "In bta_dm_remove_sec_dev_entry of bta_dm_act.cc, there is a possible out of bounds read due to a use after free. This could lead to remote information disclosure over bluetooth with no additional execution privileges needed. User interaction is not needed for exploitation.",
"id": "GHSA-hpv6-625j-5g5j",
"modified": "2024-11-20T21:30:49Z",
"published": "2024-11-20T18:32:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-9483"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2018-09-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-HPVF-P5H7-GVF4
Vulnerability from github – Published: 2022-05-14 00:55 – Updated: 2022-05-14 00:55Exiv2 0.26 has integer overflows in LoaderTiff::getData() in preview.cpp, leading to an out-of-bounds read in Exiv2::ValueType::setDataArea in value.hpp.
{
"affected": [],
"aliases": [
"CVE-2018-12264"
],
"database_specific": {
"cwe_ids": [
"CWE-125"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-06-13T11:29:00Z",
"severity": "HIGH"
},
"details": "Exiv2 0.26 has integer overflows in LoaderTiff::getData() in preview.cpp, leading to an out-of-bounds read in Exiv2::ValueType::setDataArea in value.hpp.",
"id": "GHSA-hpvf-p5h7-gvf4",
"modified": "2022-05-14T00:55:05Z",
"published": "2022-05-14T00:55:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-12264"
},
{
"type": "WEB",
"url": "https://github.com/Exiv2/exiv2/issues/366"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:2101"
},
{
"type": "WEB",
"url": "https://github.com/TeamSeri0us/pocs/blob/master/exiv2/2-out-of-read-Poc"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2018/06/msg00010.html"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/201811-14"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/3700-1"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2018/dsa-4238"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2020-04/msg00009.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HQ22-J7HH-8CF2
Vulnerability from github – Published: 2022-05-14 01:30 – Updated: 2022-05-14 01:30An issue was discovered in libmatio.a in matio (aka MAT File I/O Library) 1.5.13. There is a stack-based buffer over-read for the "Rank and Dimension" feature in the function ReadNextCell() in mat5.c.
{
"affected": [],
"aliases": [
"CVE-2019-9033"
],
"database_specific": {
"cwe_ids": [
"CWE-125"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-02-23T12:29:00Z",
"severity": "CRITICAL"
},
"details": "An issue was discovered in libmatio.a in matio (aka MAT File I/O Library) 1.5.13. There is a stack-based buffer over-read for the \"Rank and Dimension\" feature in the function ReadNextCell() in mat5.c.",
"id": "GHSA-hq22-j7hh-8cf2",
"modified": "2022-05-14T01:30:37Z",
"published": "2022-05-14T01:30:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-9033"
},
{
"type": "WEB",
"url": "https://github.com/tbeu/matio/issues/103"
},
{
"type": "WEB",
"url": "https://github.com/TeamSeri0us/pocs/tree/master/matio"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HQ29-M595-3GJQ
Vulnerability from github – Published: 2022-05-14 03:03 – Updated: 2022-05-14 03:03A pointer in an ADSPRPC command is not properly validated in all Android releases from CAF using the Linux kernel (Android for MSM, Firefox OS for MSM, QRD Android), which can lead to kernel memory being accessed.
{
"affected": [],
"aliases": [
"CVE-2018-5886"
],
"database_specific": {
"cwe_ids": [
"CWE-125"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-07-06T19:29:00Z",
"severity": "HIGH"
},
"details": "A pointer in an ADSPRPC command is not properly validated in all Android releases from CAF using the Linux kernel (Android for MSM, Firefox OS for MSM, QRD Android), which can lead to kernel memory being accessed.",
"id": "GHSA-hq29-m595-3gjq",
"modified": "2022-05-14T03:03:42Z",
"published": "2022-05-14T03:03:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-5886"
},
{
"type": "WEB",
"url": "https://source.codeaurora.org/quic/la/kernel/msm-3.18/commit/?id=97017d59158086689488bdcfcafb59654a6f10da"
},
{
"type": "WEB",
"url": "https://www.codeaurora.org/security-bulletin/2018/07/02/july-2018-code-aurora-security-bulletin"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-HQ2H-G68X-694M
Vulnerability from github – Published: 2022-05-14 01:38 – Updated: 2022-05-14 01:38An issue was discovered in Foxit 3D Plugin Beta before 9.4.0.16807 for Foxit Reader and PhantomPDF. The application could encounter an Out-of-Bounds Read in Indexing or a Heap Overflow and crash during handling of certain PDF files that embed specifically crafted 3D content, due to an array access violation.
{
"affected": [],
"aliases": [
"CVE-2019-6985"
],
"database_specific": {
"cwe_ids": [
"CWE-125"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-01-28T09:29:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in Foxit 3D Plugin Beta before 9.4.0.16807 for Foxit Reader and PhantomPDF. The application could encounter an Out-of-Bounds Read in Indexing or a Heap Overflow and crash during handling of certain PDF files that embed specifically crafted 3D content, due to an array access violation.",
"id": "GHSA-hq2h-g68x-694m",
"modified": "2022-05-14T01:38:19Z",
"published": "2022-05-14T01:38:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-6985"
},
{
"type": "WEB",
"url": "https://www.foxitsoftware.com/support/security-bulletins.php"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation MIT-5
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.
- To reduce the likelihood of introducing an out-of-bounds read, ensure that you validate and ensure correct calculations for any length argument, buffer size calculation, or offset. Be especially careful of relying on a sentinel (i.e. special character such as NUL) in untrusted inputs.
Mitigation
Strategy: Language Selection
Use a language that provides appropriate memory abstractions.
CAPEC-540: Overread Buffers
An adversary attacks a target by providing input that causes an application to read beyond the boundary of a defined buffer. This typically occurs when a value influencing where to start or stop reading is set to reflect positions outside of the valid memory location of the buffer. This type of attack may result in exposure of sensitive information, a system crash, or arbitrary code execution.