CVE-2021-29521 in TensorFlow
Summary
by MITRE • 05/15/2021
TensorFlow is an end-to-end open source platform for machine learning. Specifying a negative dense shape in `tf.raw_ops.SparseCountSparseOutput` results in a segmentation fault being thrown out from the standard library as `std::vector` invariants are broken. This is because the implementation(https://github.com/tensorflow/tensorflow/blob/8f7b60ee8c0206a2c99802e3a4d1bb55d2bc0624/tensorflow/core/kernels/count_ops.cc#L199-L213) assumes the first element of the dense shape is always positive and uses it to initialize a `BatchedMap` (i.e., `std::vector`(https://github.com/tensorflow/tensorflow/blob/8f7b60ee8c0206a2c99802e3a4d1bb55d2bc0624/tensorflow/core/kernels/count_ops.cc#L27)) data structure. If the `shape` tensor has more than one element, `num_batches` is the first value in `shape`. Ensuring that the `dense_shape` argument is a valid tensor shape (that is, all elements are non-negative) solves this issue. 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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 05/19/2021
The vulnerability CVE-2021-29521 affects the TensorFlow machine learning platform and represents a critical memory safety issue within the sparse operations implementation. This flaw manifests when the tf.raw_ops.SparseCountSparseOutput function receives a negative dense shape parameter, leading to a segmentation fault that occurs outside the TensorFlow runtime environment. The root cause stems from improper validation of input parameters within the count operations kernel implementation, specifically in the count_ops.cc file where the system assumes the first element of the dense shape is always positive without proper bounds checking.
The technical implementation flaw involves the BatchedMap data structure initialization using std::vector, which creates a direct violation of standard library invariants when negative values are processed. When a negative dense shape is provided, the code path attempts to initialize a std::vector with a negative size parameter, causing undefined behavior and ultimately a segmentation fault. The vulnerability specifically targets line 199-213 in the count_ops.cc file where the system calculates num_batches based on the first element of the shape tensor without validating that this value is positive. This design assumption breaks when the dense_shape tensor contains negative values, particularly when the shape tensor has multiple elements where the first value becomes the batch dimension.
The operational impact of this vulnerability extends beyond simple application crashes to potentially enable denial of service attacks against systems running TensorFlow applications. Attackers could exploit this weakness by crafting malicious inputs with negative dense shapes, causing segmentation faults that would terminate processes and disrupt machine learning workflows. The vulnerability affects TensorFlow versions prior to 2.5.0, with patches backported to 2.4.2 and 2.3.3, making it a significant concern for organizations maintaining older TensorFlow deployments. This issue aligns with CWE-129, which addresses improper validation of array indices and buffer bounds, and represents a classic example of how inadequate input validation can lead to memory corruption vulnerabilities.
The fix implementation addresses the core problem by ensuring proper validation of the dense_shape argument before any processing occurs, specifically verifying that all elements in the tensor shape are non-negative as required by standard tensor conventions. This validation approach follows established security practices for preventing memory safety issues and aligns with ATT&CK technique T1059.001 for executing malicious code through system vulnerabilities. The solution involves modifying the input validation logic to explicitly check tensor shape parameters against valid tensor dimension requirements, ensuring that the BatchedMap initialization receives only positive values that can be safely used to construct std::vector objects. This remediation approach prevents the exploitation of the memory corruption vulnerability while maintaining backward compatibility with valid TensorFlow operations, demonstrating a proper balance between security hardening and functional integrity. Organizations should prioritize upgrading to TensorFlow 2.5.0 or applying the cherry-picked fixes to 2.4.2 and 2.3.3 to mitigate this vulnerability effectively.