CVE-2021-37654: TensorFlow: OOB read/crash via ResourceGather batch_dims

HIGH

Published August 12, 2021

CISO Take

Any user able to execute TensorFlow code in your environment — data scientists, notebook users, shared training jobs — can crash the ML runtime or read heap memory beyond tensor bounds. Patch to TF 2.6.0, 2.5.1, 2.4.3, or 2.3.4 immediately. In multi-tenant GPU clusters or shared Jupyter environments, this is a lateral data exposure risk, not just a crash.

What is the risk?

CVSS 7.1 understates real-world risk in ML environments. 'Local' access in ML contexts means any user with notebook or training job execution rights — a standard data scientist role. Low attack complexity means no ML expertise is required: pass an out-of-range batch_dims integer to tf.raw_ops.ResourceGather and the vulnerability triggers. Confidentiality impact is HIGH because out-of-bounds heap reads can expose adjacent tensor data, potentially leaking training data, model weights, or credentials loaded into memory by co-located processes in shared GPU nodes.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
TensorFlow	pip	—	No patch
195.8K OpenSSF 7.1 3.7K dependents Pushed 3d ago 4% patched ~1372d to patch Full package profile →

Do you use TensorFlow? You're affected.

How severe is it?

CVSS 3.1

7.1 / 10

EPSS

0.2%

chance of exploitation in 30 days

Higher than 6% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AV Local

AC Low

PR Low

UI None

S Unchanged

C High

I None

A High

What should I do?

5 steps

PATCH

Upgrade to TensorFlow 2.6.0, 2.5.1, 2.4.3, or 2.3.4 — all contain commit bc9c546c.
DETECT

Audit TF version across all environments: pip show tensorflow | grep Version. Scan container images in your registry for pinned vulnerable TF versions.
WORKAROUND

If patching is blocked, add input validation to reject batch_dims values >= tensor rank before passing to tf.raw_ops.ResourceGather.
HARDEN

In shared environments, enforce process isolation per user (separate containers/VMs) to contain heap exposure.
MONITOR

Alert on TF crashes (check logs for CHECK-fail patterns) as potential exploitation indicator.

How is it classified?

DoS Data Extraction Framework Training Data AML.T0010.001 - AI Software AML.T0029 - Denial of AI Service AML.T0043 - Craft Adversarial Data

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art.15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.6 - AI system security and resilience

NIST AI RMF

MANAGE-2.2 - Mechanisms are in place to inventory AI risks

OWASP LLM Top 10

LLM06 - Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2021-37654?

Is CVE-2021-37654 actively exploited?

No confirmed active exploitation of CVE-2021-37654 has been reported, but organizations should still patch proactively.

How to fix CVE-2021-37654?

1. PATCH: Upgrade to TensorFlow 2.6.0, 2.5.1, 2.4.3, or 2.3.4 — all contain commit bc9c546c. 2. DETECT: Audit TF version across all environments: `pip show tensorflow | grep Version`. Scan container images in your registry for pinned vulnerable TF versions. 3. WORKAROUND: If patching is blocked, add input validation to reject batch_dims values >= tensor rank before passing to tf.raw_ops.ResourceGather. 4. HARDEN: In shared environments, enforce process isolation per user (separate containers/VMs) to contain heap exposure. 5. MONITOR: Alert on TF crashes (check logs for CHECK-fail patterns) as potential exploitation indicator.

What systems are affected by CVE-2021-37654?

This vulnerability affects the following AI/ML architecture patterns: training pipelines, model serving, shared ML compute clusters, embedding-based recommendation systems, transformer/NLP training infrastructure.

What is the CVSS score for CVE-2021-37654?

CVE-2021-37654 has a CVSS v3.1 base score of 7.1 (HIGH). The EPSS exploitation probability is 0.17%.

What is the AI security impact?

Affected AI Architectures

training pipelinesmodel servingshared ML compute clustersembedding-based recommendation systemstransformer/NLP training infrastructure

MITRE ATLAS Techniques

AML.T0010.001 AI Software

AML.T0029 Denial of AI Service

AML.T0043 Craft Adversarial Data

Compliance Controls Affected

EU AI Act: Art.15

ISO 42001: A.6.2.6

NIST AI RMF: MANAGE-2.2

OWASP LLM Top 10: LLM06

What are the technical details?

Original Advisory

TensorFlow is an end-to-end open source platform for machine learning. In affected versions an attacker can trigger a crash via a `CHECK`-fail in debug builds of TensorFlow using `tf.raw_ops.ResourceGather` or a read from outside the bounds of heap allocated data in the same API in a release build. The [implementation](https://github.com/tensorflow/tensorflow/blob/f24faa153ad31a4b51578f8181d3aaab77a1ddeb/tensorflow/core/kernels/resource_variable_ops.cc#L660-L668) does not check that the `batch_dims` value that the user supplies is less than the rank of the input tensor. Since the implementation uses several for loops over the dimensions of `tensor`, this results in reading data from outside the bounds of heap allocated buffer backing the tensor. We have patched the issue in GitHub commit bc9c546ce7015c57c2f15c168b3d9201de679a1d. The fix will be included in TensorFlow 2.6.0. We will also cherrypick this commit on TensorFlow 2.5.1, TensorFlow 2.4.3, and TensorFlow 2.3.4, as these are also affected and still in supported range.

Exploitation Scenario

A data scientist on a shared ML cluster submits a training job that calls tf.raw_ops.ResourceGather with a batch_dims value equal to or exceeding the input tensor's rank. In debug builds, this triggers a CHECK-fail crash that terminates the TF process, disrupting co-located training jobs. In production builds, TF iterates past heap buffer boundaries, reading memory from adjacent allocations — potentially exposing another user's in-memory training batch, embedding weights, or environment variables containing API keys loaded by the TF runtime. On multi-tenant GPU instances (common in cloud ML platforms), this becomes a cross-tenant data leak vector requiring only standard TF API access.

Weaknesses (CWE)

CWE-125 Out-of-bounds Read

CWE-125 — Out-of-bounds Read: The product reads data past the end, or before the beginning, of the intended buffer.

[Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylis
[Architecture and Design] Use a language that provides appropriate memory abstractions.

Source: MITRE CWE corpus.