PYSEC-2020-123
Vulnerability from pysec - Published: 2020-09-25 19:15 - Updated: 2021-09-01 08:19In Tensorflow before version 2.3.1, the RaggedCountSparseOutput implementation does not validate that the input arguments form a valid ragged tensor. In particular, there is no validation that the values in the splits tensor generate a valid partitioning of the values tensor. Thus, the code sets up conditions to cause a heap buffer overflow. A BatchedMap is equivalent to a vector where each element is a hashmap. However, if the first element of splits_values is not 0, batch_idx will never be 1, hence there will be no hashmap at index 0 in per_batch_counts. Trying to access that in the user code results in a segmentation fault. The issue is patched in commit 3cbb917b4714766030b28eba9fb41bb97ce9ee02 and is released in TensorFlow version 2.3.1.
| Name | purl | tensorflow | pkg:pypi/tensorflow |
|---|
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow",
"purl": "pkg:pypi/tensorflow"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3cbb917b4714766030b28eba9fb41bb97ce9ee02"
}
],
"repo": "https://github.com/tensorflow/tensorflow",
"type": "GIT"
},
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.3.1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"0.12.0rc0",
"0.12.0rc1",
"0.12.0",
"0.12.1",
"1.0.0",
"1.0.1",
"1.1.0rc0",
"1.1.0rc1",
"1.1.0rc2",
"1.1.0",
"1.2.0rc0",
"1.2.0rc1",
"1.2.0rc2",
"1.2.0",
"1.2.1",
"1.3.0rc0",
"1.3.0rc1",
"1.3.0rc2",
"1.3.0",
"1.4.0rc0",
"1.4.0rc1",
"1.4.0",
"1.4.1",
"1.5.0rc0",
"1.5.0rc1",
"1.5.0",
"1.5.1",
"1.6.0rc0",
"1.6.0rc1",
"1.6.0",
"1.7.0rc0",
"1.7.0rc1",
"1.7.0",
"1.7.1",
"1.8.0rc0",
"1.8.0rc1",
"1.8.0",
"1.9.0rc0",
"1.9.0rc1",
"1.9.0rc2",
"1.9.0",
"1.10.0rc0",
"1.10.0rc1",
"1.10.0",
"1.10.1",
"1.11.0rc0",
"1.11.0rc1",
"1.11.0rc2",
"1.11.0",
"1.12.0rc0",
"1.12.0rc1",
"1.12.0rc2",
"1.12.0",
"1.12.2",
"1.12.3",
"1.13.0rc0",
"1.13.0rc1",
"1.13.0rc2",
"1.13.1",
"1.13.2",
"1.14.0rc0",
"1.14.0rc1",
"1.14.0",
"1.15.0rc0",
"1.15.0rc1",
"1.15.0rc2",
"1.15.0rc3",
"1.15.0",
"1.15.2",
"1.15.3",
"1.15.4",
"1.15.5",
"2.0.0a0",
"2.0.0b0",
"2.0.0b1",
"2.0.0rc0",
"2.0.0rc1",
"2.0.0rc2",
"2.0.0",
"2.0.1",
"2.0.2",
"2.0.3",
"2.0.4",
"2.1.0rc0",
"2.1.0rc1",
"2.1.0rc2",
"2.1.0",
"2.1.1",
"2.1.2",
"2.1.3",
"2.2.0rc0",
"2.2.0rc1",
"2.2.0rc2",
"2.2.0rc3",
"2.2.0rc4",
"2.2.0",
"2.2.1",
"2.2.2",
"2.3.0rc0",
"2.3.0rc1",
"2.3.0rc2",
"2.3.0",
"2.1.4",
"2.2.3"
]
}
],
"aliases": [
"CVE-2020-15200",
"GHSA-x7rp-74x2-mjf3"
],
"details": "In Tensorflow before version 2.3.1, the `RaggedCountSparseOutput` implementation does not validate that the input arguments form a valid ragged tensor. In particular, there is no validation that the values in the `splits` tensor generate a valid partitioning of the `values` tensor. Thus, the code sets up conditions to cause a heap buffer overflow. A `BatchedMap` is equivalent to a vector where each element is a hashmap. However, if the first element of `splits_values` is not 0, `batch_idx` will never be 1, hence there will be no hashmap at index 0 in `per_batch_counts`. Trying to access that in the user code results in a segmentation fault. The issue is patched in commit 3cbb917b4714766030b28eba9fb41bb97ce9ee02 and is released in TensorFlow version 2.3.1.",
"id": "PYSEC-2020-123",
"modified": "2021-09-01T08:19:33.281926Z",
"published": "2020-09-25T19:15:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://github.com/tensorflow/tensorflow/security/advisories/GHSA-x7rp-74x2-mjf3"
},
{
"type": "WEB",
"url": "https://github.com/tensorflow/tensorflow/releases/tag/v2.3.1"
},
{
"type": "FIX",
"url": "https://github.com/tensorflow/tensorflow/commit/3cbb917b4714766030b28eba9fb41bb97ce9ee02"
}
]
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.