admin/cvelist
1
0
Fork 0
mirror of https://github.com/CVEProject/cvelist.git synced 2025-07-29 05:56:59 +00:00
Code Issues Packages Projects Releases Wiki Activity

"-Synchronized-Data."

Browse Source
This commit is contained in:
CVE Team 2022-11-10 20:00:36 +00:00
parent 1984147cfa
commit 8b3de4fd4f
No known key found for this signature in database
GPG Key ID: E3252B3D49582C98
4 changed files with 120 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
2022/24xxx/CVE-2022-24945.json
View File

@ -1,17 +1,17 @@
{
"data_version": "4.0",
"data_type": "CVE",
"data_format": "MITRE",
"data_version": "4.0",
"CVE_data_meta": {
"ID": "CVE-2022-24945",
"ASSIGNER": "product-security@silabs.com",
"ASSIGNER": "cve@mitre.org",
"STATE": "REJECT"
},
"description": {
"description_data": [
{
"lang": "eng",
"value": "This CVE ID has been rejected or withdrawn by its CVE Numbering Authority."
"value": "** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: none."
}
]
}

2
2022/39xxx/CVE-2022-39392.json
View File

@ -35,7 +35,7 @@
"description_data": [
{
"lang": "eng",
"value": "Wasmtime is a standalone runtime for WebAssembly. Prior to version 2.0.2, there is a bug in Wasmtime's implementation of its pooling instance allocator when the allocator is configured to give WebAssembly instances a maximum of zero pages of memory. In this configuration, the virtual memory mapping for WebAssembly memories did not meet the compiler-required configuration requirements for safely executing WebAssembly modules. Wasmtime's default settings require virtual memory page faults to indicate that wasm reads/writes are out-of-bounds, but the pooling allocator's configuration would not create an appropriate virtual memory mapping for this meaning out of bounds reads/writes can successfully read/write memory unrelated to the wasm sandbox within range of the base address of the memory mapping created by the pooling allocator. \n\nThis bug is not applicable with the default settings of the `wasmtime` crate. This bug can only be triggered by setting `InstanceLimits::memory_pages` to zero. This is expected to be a very rare configuration since this means that wasm modules cannot allocate any pages of linear memory. All wasm modules produced by all current toolchains are highly likely to use linear memory, so it's expected to be unlikely that this configuration is set to zero by any production embedding of Wasmtime.\n\nThis bug has been patched and users should upgrade to Wasmtime 2.0.2. This bug can be worked around by increasing the `memory_pages` allotment when configuring the pooling allocator to a value greater than zero. If an embedding wishes to still prevent memory from actually being used then the `Store::limiter` method can be used to dynamically disallow growth of memory beyond 0 bytes large. Note that the default `memory_pages` value is greater than zero.\n"
"value": "Wasmtime is a standalone runtime for WebAssembly. Prior to version 2.0.2, there is a bug in Wasmtime's implementation of its pooling instance allocator when the allocator is configured to give WebAssembly instances a maximum of zero pages of memory. In this configuration, the virtual memory mapping for WebAssembly memories did not meet the compiler-required configuration requirements for safely executing WebAssembly modules. Wasmtime's default settings require virtual memory page faults to indicate that wasm reads/writes are out-of-bounds, but the pooling allocator's configuration would not create an appropriate virtual memory mapping for this meaning out of bounds reads/writes can successfully read/write memory unrelated to the wasm sandbox within range of the base address of the memory mapping created by the pooling allocator. This bug is not applicable with the default settings of the `wasmtime` crate. This bug can only be triggered by setting `InstanceLimits::memory_pages` to zero. This is expected to be a very rare configuration since this means that wasm modules cannot allocate any pages of linear memory. All wasm modules produced by all current toolchains are highly likely to use linear memory, so it's expected to be unlikely that this configuration is set to zero by any production embedding of Wasmtime. This bug has been patched and users should upgrade to Wasmtime 2.0.2. This bug can be worked around by increasing the `memory_pages` allotment when configuring the pooling allocator to a value greater than zero. If an embedding wishes to still prevent memory from actually being used then the `Store::limiter` method can be used to dynamically disallow growth of memory beyond 0 bytes large. Note that the default `memory_pages` value is greater than zero."
}
]
},

71
2022/41xxx/CVE-2022-41719.json
View File

@ -1,18 +1,79 @@
{
"data_version": "4.0",
"data_type": "CVE",
"data_format": "MITRE",
"data_version": "4.0",
"CVE_data_meta": {
"ID": "CVE-2022-41719",
"ASSIGNER": "cve@mitre.org",
"STATE": "RESERVED"
"ASSIGNER": "security@golang.org",
"STATE": "PUBLIC"
},
"description": {
"description_data": [
{
"lang": "eng",
"value": "** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided."
"value": "Unmarshal can panic on some inputs, possibly allowing for denial of service attacks."
}
]
}
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "eng",
"value": "CWE 400: Uncontrolled Resource Consumption"
}
]
}
]
},
"affects": {
"vendor": {
"vendor_data": [
{
"vendor_name": "github.com/shamaton/msgpack/v2",
"product": {
"product_data": [
{
"product_name": "github.com/shamaton/msgpack/v2",
"version": {
"version_data": [
{
"version_value": "0",
"version_affected": "="
}
]
}
}
]
}
}
]
}
},
"references": {
"reference_data": [
{
"url": "https://github.com/shamaton/msgpack/issues/31",
"refsource": "MISC",
"name": "https://github.com/shamaton/msgpack/issues/31"
},
{
"url": "https://github.com/shamaton/msgpack/pull/32",
"refsource": "MISC",
"name": "https://github.com/shamaton/msgpack/pull/32"
},
{
"url": "https://pkg.go.dev/vuln/GO-2022-0972",
"refsource": "MISC",
"name": "https://pkg.go.dev/vuln/GO-2022-0972"
}
]
},
"credits": [
{
"lang": "en",
"value": "Red Canary"
}
]
}

56
2022/43xxx/CVE-2022-43074.json
View File

@ -1,17 +1,61 @@
{
"data_type": "CVE",
"data_format": "MITRE",
"data_version": "4.0",
"CVE_data_meta": {
"ID": "CVE-2022-43074",
"ASSIGNER": "cve@mitre.org",
"STATE": "RESERVED"
"ID": "CVE-2022-43074",
"STATE": "PUBLIC"
},
"affects": {
"vendor": {
"vendor_data": [
{
"product": {
"product_data": [
{
"product_name": "n/a",
"version": {
"version_data": [
{
"version_value": "n/a"
}
]
}
}
]
},
"vendor_name": "n/a"
}
]
}
},
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "eng",
"value": "** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided."
"value": "AyaCMS v3.1.2 was discovered to contain an arbitrary file upload vulnerability via the component /admin/fst_upload.inc.php. This vulnerability allows attackers to execute arbitrary code via a crafted PHP file."
}
]
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "eng",
"value": "n/a"
}
]
}
]
},
"references": {
"reference_data": [
{
"url": "https://github.com/loadream/AyaCMS/issues/3",
"refsource": "MISC",
"name": "https://github.com/loadream/AyaCMS/issues/3"
}
]
}