CVE-2020-15196
published 2020-09-25CVE-2020-15196: In Tensorflow version 2.3.0, the `SparseCountSparseOutput` and `RaggedCountSparseOutput` implementations don't validate that the `weights` tensor has the same…
PriorityP348critical9.9CVSS 3.1
AVNACLPRLUINSCCHIHAH
EPSS
0.90%
55.5th percentile
In Tensorflow version 2.3.0, the `SparseCountSparseOutput` and `RaggedCountSparseOutput` implementations don't validate that the `weights` tensor has the same shape as the data. The check exists for `DenseCountSparseOutput`, where both tensors are fully specified. In the sparse and ragged count weights are still accessed in parallel with the data. But, since there is no validation, a user passing fewer weights than the values for the tensors can generate a read from outside the bounds of the heap buffer allocated for the weights. The issue is patched in commit 3cbb917b4714766030b28eba9fb41bb97ce9ee02 and is released in TensorFlow version 2.3.1.
Affected
6 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | tensorflow | — | — |
| tensorflow | — | — | |
| intel | optimization_for_tensorflow | >= 0 < 3cbb917b4714766030b28eba9fb41bb97ce9ee02 | 3cbb917b4714766030b28eba9fb41bb97ce9ee02 |
| intel | optimization_for_tensorflow | >= 0 < 2.3.1 | 2.3.1 |
| intel | optimization_for_tensorflow | >= 2.3.0 < 2.3.1 | 2.3.1 |
| tensorflow | tensorflow | — | — |
CVSS provenance
nvdv3.19.9CRITICALCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
nvdv2.06.5MEDIUMAV:N/AC:L/Au:S/C:P/I:P/A:P
vendor_debian8.5LOW
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
GHSA
Heap buffer overflow in Tensorflow
ghsa·2020-09-25
CVE-2020-15196 [MEDIUM] CWE-119 Heap buffer overflow in Tensorflow
Heap buffer overflow in Tensorflow
### Impact
The `SparseCountSparseOutput` and `RaggedCountSparseOutput` implementations don't validate that the `weights` tensor has the same shape as the data. The check exists for `DenseCountSparseOutput`, where both tensors are fully specified:
https://github.com/tensorflow/tensorflow/blob/0e68f4d3295eb0281a517c3662f6698992b7b2cf/tensorflow/core/kernels/count_ops.cc#L110-L117
In the sparse and ragged count weights are still accessed in parallel with the data:
https://github.com/tensorflow/tensorflow/blob/0e68f4d3295eb0281a517c3662f6698992b7b2cf/tensorflow/core/kernels/count_ops.cc#L199-L201
But, since there is no validation, a user passing fewer weights than the values for the tensors can generate a read from outside the bounds of the heap buffer all
OSV
CVE-2020-15196: In Tensorflow version 2
osv·2020-09-25
CVE-2020-15196 CVE-2020-15196: In Tensorflow version 2
In Tensorflow version 2.3.0, the `SparseCountSparseOutput` and `RaggedCountSparseOutput` implementations don't validate that the `weights` tensor has the same shape as the data. The check exists for `DenseCountSparseOutput`, where both tensors are fully specified. In the sparse and ragged count weights are still accessed in parallel with the data. But, since there is no validation, a user passing fewer weights than the values for the tensors can generate a read from outside the bounds of the heap buffer allocated for the weights. The issue is patched in commit 3cbb917b4714766030b28eba9fb41bb97ce9ee02 and is released in TensorFlow version 2.3.1.
OSV
Heap buffer overflow in Tensorflow
osv·2020-09-25
CVE-2020-15196 [MEDIUM] Heap buffer overflow in Tensorflow
Heap buffer overflow in Tensorflow
### Impact
The `SparseCountSparseOutput` and `RaggedCountSparseOutput` implementations don't validate that the `weights` tensor has the same shape as the data. The check exists for `DenseCountSparseOutput`, where both tensors are fully specified:
https://github.com/tensorflow/tensorflow/blob/0e68f4d3295eb0281a517c3662f6698992b7b2cf/tensorflow/core/kernels/count_ops.cc#L110-L117
In the sparse and ragged count weights are still accessed in parallel with the data:
https://github.com/tensorflow/tensorflow/blob/0e68f4d3295eb0281a517c3662f6698992b7b2cf/tensorflow/core/kernels/count_ops.cc#L199-L201
But, since there is no validation, a user passing fewer weights than the values for the tensors can generate a read from outside the bounds of the heap buffer all
Debian
CVE-2020-15196: tensorflow - In Tensorflow version 2.3.0, the `SparseCountSparseOutput` and `RaggedCountSpars...
vendor_debian·2020·CVSS 8.5
CVE-2020-15196 [HIGH] CVE-2020-15196: tensorflow - In Tensorflow version 2.3.0, the `SparseCountSparseOutput` and `RaggedCountSpars...
In Tensorflow version 2.3.0, the `SparseCountSparseOutput` and `RaggedCountSparseOutput` implementations don't validate that the `weights` tensor has the same shape as the data. The check exists for `DenseCountSparseOutput`, where both tensors are fully specified. In the sparse and ragged count weights are still accessed in parallel with the data. But, since there is no validation, a user passing fewer weights than the values for the tensors can generate a read from outside the bounds of the heap buffer allocated for the weights. The issue is patched in commit 3cbb917b4714766030b28eba9fb41bb97ce9ee02 and is released in TensorFlow version 2.3.1.
Scope: local
forky: resolved
sid: resolved
No detection rules found.
No public exploits indexed.
No writeups or analysis indexed.
https://github.com/tensorflow/tensorflow/commit/3cbb917b4714766030b28eba9fb41bb97ce9ee02https://github.com/tensorflow/tensorflow/releases/tag/v2.3.1https://github.com/tensorflow/tensorflow/security/advisories/GHSA-pg59-2f92-5cphhttps://github.com/tensorflow/tensorflow/commit/3cbb917b4714766030b28eba9fb41bb97ce9ee02https://github.com/tensorflow/tensorflow/releases/tag/v2.3.1https://github.com/tensorflow/tensorflow/security/advisories/GHSA-pg59-2f92-5cph
2020-09-25
Published