pysec-2021-151
Vulnerability from pysec
TensorFlow is an end-to-end open source platform for machine learning. If the splits
argument of RaggedBincount
does not specify a valid SparseTensor
(https://www.tensorflow.org/api_docs/python/tf/sparse/SparseTensor), then an attacker can trigger a heap buffer overflow. This will cause a read from outside the bounds of the splits
tensor buffer in the implementation of the RaggedBincount
op(https://github.com/tensorflow/tensorflow/blob/8b677d79167799f71c42fd3fa074476e0295413a/tensorflow/core/kernels/bincount_op.cc#L430-L446). Before the for
loop, batch_idx
is set to 0. The attacker sets splits(0)
to be 7, hence the while
loop does not execute and batch_idx
remains 0. This then results in writing to out(-1, bin)
, which is before the heap allocated buffer for the output tensor. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2 and TensorFlow 2.3.3, as these are also affected.
{ "affected": [ { "package": { "ecosystem": "PyPI", "name": "tensorflow", "purl": "pkg:pypi/tensorflow" }, "ranges": [ { "events": [ { "introduced": "0" }, { "fixed": "eebb96c2830d48597d055d247c0e9aebaea94cd5" } ], "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-29514", "GHSA-8h46-5m9h-7553" ], "details": "TensorFlow is an end-to-end open source platform for machine learning. If the `splits` argument of `RaggedBincount` does not specify a valid `SparseTensor`(https://www.tensorflow.org/api_docs/python/tf/sparse/SparseTensor), then an attacker can trigger a heap buffer overflow. This will cause a read from outside the bounds of the `splits` tensor buffer in the implementation of the `RaggedBincount` op(https://github.com/tensorflow/tensorflow/blob/8b677d79167799f71c42fd3fa074476e0295413a/tensorflow/core/kernels/bincount_op.cc#L430-L446). Before the `for` loop, `batch_idx` is set to 0. The attacker sets `splits(0)` to be 7, hence the `while` loop does not execute and `batch_idx` remains 0. This then results in writing to `out(-1, bin)`, which is before the heap allocated buffer for the output tensor. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2 and TensorFlow 2.3.3, as these are also affected.", "id": "PYSEC-2021-151", "modified": "2021-08-27T03:22:23.861341Z", "published": "2021-05-14T20:15:00Z", "references": [ { "type": "FIX", "url": "https://github.com/tensorflow/tensorflow/commit/eebb96c2830d48597d055d247c0e9aebaea94cd5" }, { "type": "ADVISORY", "url": "https://github.com/tensorflow/tensorflow/security/advisories/GHSA-8h46-5m9h-7553" } ] }
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.