pysec-2021-169
Vulnerability from pysec
TensorFlow is an end-to-end open source platform for machine learning. An attacker can force accesses outside the bounds of heap allocated arrays by passing in invalid tensor values to tf.raw_ops.RaggedCross. This is because the implementation(https://github.com/tensorflow/tensorflow/blob/efea03b38fb8d3b81762237dc85e579cc5fc6e87/tensorflow/core/kernels/ragged_cross_op.cc#L456-L487) lacks validation for the user supplied arguments. Each of the above branches call a helper function after accessing array elements via a *_list[next_*] pattern, followed by incrementing the next_* index. However, as there is no validation that the next_* values are in the valid range for the corresponding *_list arrays, this results in heap OOB reads. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow",
"purl": "pkg:pypi/tensorflow"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "44b7f486c0143f68b56c34e2d01e146ee445134a"
}
],
"repo": "https://github.com/tensorflow/tensorflow",
"type": "GIT"
},
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.2.0rc0"
},
{
"introduced": "2.2.0"
},
{
"fixed": "2.3.0rc0"
},
{
"introduced": "2.3.0"
},
{
"fixed": "2.3.4"
},
{
"introduced": "2.4.0"
},
{
"fixed": "2.4.3"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"0.12.0",
"0.12.0rc0",
"0.12.0rc1",
"0.12.1",
"1.0.0",
"1.0.1",
"1.1.0",
"1.1.0rc0",
"1.1.0rc1",
"1.1.0rc2",
"1.10.0",
"1.10.0rc0",
"1.10.0rc1",
"1.10.1",
"1.11.0",
"1.11.0rc0",
"1.11.0rc1",
"1.11.0rc2",
"1.12.0",
"1.12.0rc0",
"1.12.0rc1",
"1.12.0rc2",
"1.12.2",
"1.12.3",
"1.13.0rc0",
"1.13.0rc1",
"1.13.0rc2",
"1.13.1",
"1.13.2",
"1.14.0",
"1.14.0rc0",
"1.14.0rc1",
"1.15.0",
"1.15.0rc0",
"1.15.0rc1",
"1.15.0rc2",
"1.15.0rc3",
"1.15.2",
"1.15.3",
"1.15.4",
"1.15.5",
"1.2.0",
"1.2.0rc0",
"1.2.0rc1",
"1.2.0rc2",
"1.2.1",
"1.3.0",
"1.3.0rc0",
"1.3.0rc1",
"1.3.0rc2",
"1.4.0",
"1.4.0rc0",
"1.4.0rc1",
"1.4.1",
"1.5.0",
"1.5.0rc0",
"1.5.0rc1",
"1.5.1",
"1.6.0",
"1.6.0rc0",
"1.6.0rc1",
"1.7.0",
"1.7.0rc0",
"1.7.0rc1",
"1.7.1",
"1.8.0",
"1.8.0rc0",
"1.8.0rc1",
"1.9.0",
"1.9.0rc0",
"1.9.0rc1",
"1.9.0rc2",
"2.0.0",
"2.0.0a0",
"2.0.0b0",
"2.0.0b1",
"2.0.0rc0",
"2.0.0rc1",
"2.0.0rc2",
"2.0.1",
"2.0.2",
"2.0.3",
"2.0.4",
"2.1.0",
"2.1.0rc0",
"2.1.0rc1",
"2.1.0rc2",
"2.1.1",
"2.1.2",
"2.1.3",
"2.1.4",
"2.2.0",
"2.2.1",
"2.2.2",
"2.2.3",
"2.3.0",
"2.3.1",
"2.3.2",
"2.3.3",
"2.4.0",
"2.4.1",
"2.4.2"
]
}
],
"aliases": [
"CVE-2021-29532",
"GHSA-j47f-4232-hvv8"
],
"details": "TensorFlow is an end-to-end open source platform for machine learning. An attacker can force accesses outside the bounds of heap allocated arrays by passing in invalid tensor values to `tf.raw_ops.RaggedCross`. This is because the implementation(https://github.com/tensorflow/tensorflow/blob/efea03b38fb8d3b81762237dc85e579cc5fc6e87/tensorflow/core/kernels/ragged_cross_op.cc#L456-L487) lacks validation for the user supplied arguments. Each of the above branches call a helper function after accessing array elements via a `*_list[next_*]` pattern, followed by incrementing the `next_*` index. However, as there is no validation that the `next_*` values are in the valid range for the corresponding `*_list` arrays, this results in heap OOB reads. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.",
"id": "PYSEC-2021-169",
"modified": "2021-08-27T03:22:27.051975Z",
"published": "2021-05-14T20:15:00Z",
"references": [
{
"type": "FIX",
"url": "https://github.com/tensorflow/tensorflow/commit/44b7f486c0143f68b56c34e2d01e146ee445134a"
},
{
"type": "ADVISORY",
"url": "https://github.com/tensorflow/tensorflow/security/advisories/GHSA-j47f-4232-hvv8"
}
]
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.