CVE-2021-29545 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 converting sparse tensors to CSR Sparse matrices. This is because the implementation(https://github.com/tensorflow/tensorflow/blob/800346f2c03a27e182dd4fba48295f65e7790739/tensorflow/core/kernels/sparse/kernels.cc#L66) does a double redirection to access an element of an array allocated on the heap. If the value at `indices(i, 0)` is such that `indices(i, 0) + 1` is outside the bounds of `csr_row_ptr`, this results in writing outside of bounds of heap allocated data. 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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 05/19/2021
The vulnerability CVE-2021-29545 affects TensorFlow, a widely-used open-source machine learning platform that processes sparse tensor operations through CSR (Compressed Sparse Row) format conversion. This issue stems from a critical flaw in the kernel implementation responsible for transforming sparse tensors into CSR matrices, where a specific boundary condition triggers a denial of service condition. The vulnerability manifests when the system attempts to access heap-allocated memory through double redirection mechanisms during sparse tensor processing, creating a scenario where memory corruption occurs outside the intended bounds of allocated data structures.
The technical implementation flaw occurs within the sparse kernels.cc file at line 66, where the code performs a double redirection to access array elements allocated on the heap. This pattern creates a dangerous condition where the value at indices(i, 0) is used to calculate an offset that should reference the csr_row_ptr array. When indices(i, 0) + 1 exceeds the valid bounds of the csr_row_ptr array, the system writes beyond the allocated heap memory boundaries, resulting in a CHECK-fail that terminates the application. This type of vulnerability falls under CWE-121, which describes stack-based buffer overflow conditions, and represents a classic example of out-of-bounds memory access that can lead to arbitrary code execution or denial of service.
The operational impact of this vulnerability extends across multiple TensorFlow versions, with affected releases including TensorFlow 2.1.4, 2.2.3, 2.3.3, 2.4.2, and the vulnerable state existing in the mainline TensorFlow 2.5.0 release. Attackers can exploit this weakness by crafting malicious sparse tensor inputs that trigger the specific boundary condition, leading to system crashes and denial of service conditions. The vulnerability is particularly concerning in production environments where TensorFlow serves as a core component of machine learning pipelines, as it can be leveraged to disrupt services without requiring elevated privileges or specialized attack vectors. The fix addresses the root cause by implementing proper bounds checking before memory access operations, ensuring that all array indices remain within valid memory boundaries during the sparse tensor conversion process.
Mitigation strategies should focus on immediate patching of affected TensorFlow versions to prevent exploitation, with administrators prioritizing updates to TensorFlow 2.5.0 or applying the cherry-picked fixes to older supported versions. The vulnerability demonstrates the importance of proper input validation and bounds checking in memory-intensive operations, particularly in mathematical libraries that process large datasets. Organizations should also implement monitoring for unusual system behavior or application crashes that could indicate exploitation attempts. This issue aligns with ATT&CK technique T1499.004, which covers network denial of service, and highlights the need for robust memory safety practices in machine learning frameworks that handle user-provided data inputs. The vulnerability serves as a reminder that even seemingly benign operations in mathematical computing libraries can present significant security risks when proper bounds checking is absent from critical code paths.