Page 71 of 374 results (0.022 seconds)

CVSS: 4.3EPSS: 0%CPEs: 2EXPL: 1

In TensorFlow Lite before versions 2.2.1 and 2.3.1, models using segment sum can trigger a denial of service by causing an out of memory allocation in the implementation of segment sum. Since code uses the last element of the tensor holding them to determine the dimensionality of output tensor, attackers can use a very large value to trigger a large allocation. The issue is patched in commit 204945b19e44b57906c9344c0d00120eeeae178a and is released in TensorFlow versions 2.2.1, or 2.3.1. A potential workaround would be to add a custom `Verifier` to limit the maximum value in the segment ids tensor. This only handles the case when the segment ids are stored statically in the model, but a similar validation could be done if the segment ids are generated at runtime, between inference steps. • https://github.com/tensorflow/tensorflow/commit/204945b19e44b57906c9344c0d00120eeeae178a https://github.com/tensorflow/tensorflow/releases/tag/v2.3.1 https://github.com/tensorflow/tensorflow/security/advisories/GHSA-hjmq-236j-8m87 • CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer CWE-770: Allocation of Resources Without Limits or Throttling •

CVSS: 8.1EPSS: 0%CPEs: 2EXPL: 1

In TensorFlow Lite before versions 2.2.1 and 2.3.1, models using segment sum can trigger a write out bounds / segmentation fault if the segment ids are not sorted. Code assumes that the segment ids are in increasing order, using the last element of the tensor holding them to determine the dimensionality of output tensor. This results in allocating insufficient memory for the output tensor and in a write outside the bounds of the output array. This usually results in a segmentation fault, but depending on runtime conditions it can provide for a write gadget to be used in future memory corruption-based exploits. The issue is patched in commit 204945b19e44b57906c9344c0d00120eeeae178a and is released in TensorFlow versions 2.2.1, or 2.3.1. • https://github.com/tensorflow/tensorflow/commit/204945b19e44b57906c9344c0d00120eeeae178a https://github.com/tensorflow/tensorflow/releases/tag/v2.3.1 https://github.com/tensorflow/tensorflow/security/advisories/GHSA-p2cq-cprg-frvm • CWE-787: Out-of-bounds Write •

CVSS: 6.8EPSS: 0%CPEs: 1EXPL: 1

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. Hence, the code is prone to heap buffer overflow. If `split_values` does not end with a value at least `num_values` then the `while` loop condition will trigger a read outside of the bounds of `split_values` once `batch_idx` grows too large. The issue is patched in commit 3cbb917b4714766030b28eba9fb41bb97ce9ee02 and is released in TensorFlow version 2.3.1. • https://github.com/tensorflow/tensorflow/commit/3cbb917b4714766030b28eba9fb41bb97ce9ee02 https://github.com/tensorflow/tensorflow/releases/tag/v2.3.1 https://github.com/tensorflow/tensorflow/security/advisories/GHSA-p5f8-gfw5-33w4 • CWE-20: Improper Input Validation CWE-122: Heap-based Buffer Overflow CWE-787: Out-of-bounds Write •

CVSS: 9.0EPSS: 0%CPEs: 6EXPL: 1

In Tensorflow before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, the `Shard` API in TensorFlow expects the last argument to be a function taking two `int64` (i.e., `long long`) arguments. However, there are several places in TensorFlow where a lambda taking `int` or `int32` arguments is being used. In these cases, if the amount of work to be parallelized is large enough, integer truncation occurs. Depending on how the two arguments of the lambda are used, this can result in segfaults, read/write outside of heap allocated arrays, stack overflows, or data corruption. The issue is patched in commits 27b417360cbd671ef55915e4bb6bb06af8b8a832 and ca8c013b5e97b1373b3bb1c97ea655e69f31a575, and is released in TensorFlow versions 1.15.4, 2.0.3, 2.1.2, 2.2.1, or 2.3.1. • http://lists.opensuse.org/opensuse-security-announce/2020-10/msg00065.html https://github.com/tensorflow/tensorflow/commit/27b417360cbd671ef55915e4bb6bb06af8b8a832 https://github.com/tensorflow/tensorflow/commit/ca8c013b5e97b1373b3bb1c97ea655e69f31a575 https://github.com/tensorflow/tensorflow/releases/tag/v2.3.1 https://github.com/tensorflow/tensorflow/security/advisories/GHSA-h6fg-mjxg-hqq4 • CWE-197: Numeric Truncation Error CWE-754: Improper Check for Unusual or Exceptional Conditions •

CVSS: 7.5EPSS: 0%CPEs: 6EXPL: 1

In Tensorflow before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, by controlling the `fill` argument of tf.strings.as_string, a malicious attacker is able to trigger a format string vulnerability due to the way the internal format use in a `printf` call is constructed. This may result in segmentation fault. The issue is patched in commit 33be22c65d86256e6826666662e40dbdfe70ee83, and is released in TensorFlow versions 1.15.4, 2.0.3, 2.1.2, 2.2.1, or 2.3.1. En Tensorflow versiones anteriores a 1.15.4, 2.0.3, 2.1.2, 2.2.1 y 2.3.1, al controlar el argumento "fill" de tf.strings.as_string, un atacante malicioso puede desencadenar una vulnerabilidad de cadena de formato debido a la manera en que se construye el uso del formato interno en una llamada de "printf". Esto puede resultar en un fallo de segmentación. • http://lists.opensuse.org/opensuse-security-announce/2020-10/msg00065.html https://github.com/tensorflow/tensorflow/commit/33be22c65d86256e6826666662e40dbdfe70ee83 https://github.com/tensorflow/tensorflow/releases/tag/v2.3.1 https://github.com/tensorflow/tensorflow/security/advisories/GHSA-xmq7-7fxm-rr79 • CWE-20: Improper Input Validation CWE-134: Use of Externally-Controlled Format String •