CVE-2021-29523 in TensorFlow
Summary
by MITRE • 05/15/2021
TensorFlow is an end-to-end open source platform for machine learning. An attacker can trigger a denial of service via a `CHECK`-fail in `tf.raw_ops.AddManySparseToTensorsMap`. This is because the implementation(https://github.com/tensorflow/tensorflow/blob/6f9896890c4c703ae0a0845394086e2e1e523299/tensorflow/core/kernels/sparse_tensors_map_ops.cc#L257) takes the values specified in `sparse_shape` as dimensions for the output shape. The `TensorShape` constructor(https://github.com/tensorflow/tensorflow/blob/6f9896890c4c703ae0a0845394086e2e1e523299/tensorflow/core/framework/tensor_shape.cc#L183-L188) uses a `CHECK` operation which triggers when `InitDims`(https://github.com/tensorflow/tensorflow/blob/6f9896890c4c703ae0a0845394086e2e1e523299/tensorflow/core/framework/tensor_shape.cc#L212-L296) returns a non-OK status. This is a legacy implementation of the constructor and operations should use `BuildTensorShapeBase` or `AddDimWithStatus` to prevent `CHECK`-failures in the presence of overflows. 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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 05/16/2021
The vulnerability described in CVE-2021-29523 affects TensorFlow's handling of sparse tensor operations, specifically within the `tf.raw_ops.AddManySparseToTensorsMap` function. This issue represents a denial of service condition that can be triggered by malicious input, making it particularly concerning for systems that process untrusted data through machine learning pipelines. The flaw stems from how TensorFlow interprets sparse tensor shapes during the construction of output tensors, creating a scenario where malformed input can cause the system to crash rather than gracefully handle the error.
The technical root cause lies in the implementation of the `TensorShape` constructor which relies on a `CHECK` operation that fails when dimension values exceed acceptable bounds. When processing sparse tensor shapes, the code at line 257 of `sparse_tensors_map_ops.cc` directly uses values from `sparse_shape` as dimensions for output tensor construction. The `TensorShape` constructor at lines 183-188 in `tensor_shape.cc` employs a `CHECK` mechanism that terminates execution when `InitDims` returns a non-OK status. This legacy implementation pattern violates modern defensive programming principles and creates an attack surface where controlled input can cause process termination rather than proper error handling.
This vulnerability aligns with CWE-682, which describes incorrect arithmetic operations that can lead to unexpected behavior including crashes or denial of service conditions. The flaw specifically manifests when tensor dimensions exceed the valid range for tensor shape construction, causing the CHECK operation to fail and resulting in process termination. From an operational perspective, this vulnerability impacts TensorFlow deployments where untrusted inputs are processed, particularly in web applications or APIs that accept user-supplied tensor specifications. The issue affects multiple TensorFlow versions including 2.1.4 through 2.5.0, making it a widespread concern for organizations maintaining legacy systems.
The attack vector involves an adversary providing carefully crafted sparse tensor shape specifications that cause the tensor shape constructor to fail during dimension validation. This creates a denial of service condition where legitimate operations cannot proceed due to the system crashing on malformed input. The vulnerability is particularly dangerous in production environments where TensorFlow is used to process user inputs, as it can be exploited to disrupt services without requiring elevated privileges or complex attack chains. Organizations should note that this vulnerability affects TensorFlow versions 2.1.4 through 2.4.1, with fixes planned for 2.5.0 and backported to older supported releases.
Mitigation strategies should focus on upgrading to patched TensorFlow versions or implementing input validation layers that prevent malformed sparse tensor specifications from reaching the vulnerable code paths. System administrators should prioritize updating to TensorFlow 2.5.0 or the appropriate patch versions for their supported releases. The fix addresses the core issue by replacing the legacy `CHECK`-based implementation with safer alternatives such as `BuildTensorShapeBase` or `AddDimWithStatus` that properly handle overflow conditions without causing process termination. Additionally, organizations should consider implementing monitoring and alerting for unexpected process terminations that could indicate exploitation attempts, and establish proper input sanitization procedures for any TensorFlow operations handling untrusted data sources.