VYPR
← All advisories
Moderate severityNVD Advisory· Published Feb 3, 2022· Updated Feb 12, 2025

Memory exhaustion in Tensorflow

CVE-2022-21732

Description

TensorFlow's ThreadPoolHandle lacks upper bound on num_threads, allowing memory exhaustion DoS. Fixed in 2.8.0, backported to 2.7.1, 2.6.3, 2.5.3.

AI Insight

LLM-synthesized narrative grounded in this CVE's description and references.

TensorFlow's ThreadPoolHandle lacks upper bound on num_threads, allowing memory exhaustion DoS. Fixed in 2.8.0, backported to 2.7.1, 2.6.3, 2.5.3.

Vulnerability

The ThreadPoolHandle and PrivateThreadPoolDatasetOp implementations in TensorFlow do not enforce an upper bound on the num_threads parameter. The parameter is only validated to be non-negative, allowing an attacker to specify an extremely large value. This can lead to excessive memory allocation proportional to the specified thread count. Affected versions include TensorFlow 2.5.x, 2.6.x, 2.7.x, and earlier, prior to the fix [1][4].

Exploitation

An attacker can provide a large num_threads value when invoking the threadpool_dataset API or similar operations. No special privileges or user interaction beyond the ability to provide input to a TensorFlow model are required. The attacker simply sets num_threads to a very high number, triggering the allocation of a thread pool with that many threads, which consumes excessive memory and leads to denial of service [1][3].

Impact

Successful exploitation results in a denial of service, as the TensorFlow process may crash or become unresponsive due to memory exhaustion. The impact is limited to availability (A) without loss of confidentiality or integrity [1].

Mitigation

TensorFlow has fixed the issue by introducing a constant kThreadLimit of 65536 and validating that num_threads is below this limit [3]. The fix is included in TensorFlow 2.8.0 and has been cherry-picked to versions 2.7.1, 2.6.3, and 2.5.3. Users should upgrade to these patched versions or apply the corresponding commit [1][3].

References
  1. NVD - CVE-2022-21732
  2. [tf.data] Set limit on number of threads used in threadpool_dataset. · tensorflow/tensorflow@e3749a6
  3. tensorflow/tensorflow/core/kernels/data/experimental/threadpool_dataset_op.cc at 5100e359aef5c8021f2e71c7b986420b85ce7b3d · tensorflow/tensorflow

AI Insight generated on May 21, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.

Affected packages

Versions sourced from the GitHub Security Advisory.

PackageAffected versionsPatched versions
tensorflowPyPI
< 2.5.32.5.3
tensorflowPyPI
>= 2.6.0, < 2.6.32.6.3
tensorflowPyPI
>= 2.7.0, < 2.7.12.7.1
tensorflow-cpuPyPI
< 2.5.32.5.3
tensorflow-cpuPyPI
>= 2.6.0, < 2.6.32.6.3
tensorflow-cpuPyPI
>= 2.7.0, < 2.7.12.7.1
tensorflow-gpuPyPI
< 2.5.32.5.3
tensorflow-gpuPyPI
>= 2.6.0, < 2.6.32.6.3
tensorflow-gpuPyPI
>= 2.7.0, < 2.7.12.7.1

Affected products

5

Patches

1
e3749a6d5d1e

[tf.data] Set limit on number of threads used in threadpool_dataset.

https://github.com/tensorflow/tensorflowAndrew AudibertNov 19, 2021via ghsa
commit
1 file changed · +19 −7
  • tensorflow/core/kernels/data/experimental/threadpool_dataset_op.cc+19 −7 modified
    @@ -39,6 +39,22 @@ namespace experimental {
     PrivateThreadPoolDatasetOp::kDatasetType;
 /* static */ constexpr const char* const PrivateThreadPoolDatasetOp::kDatasetOp;
 
+namespace {
+// To prevent integer overflow issues when allocating threadpool memory for an
+// unreasonable number of threads.
+constexpr int kThreadLimit = 65536;
+
+Status ValidateNumThreads(int32_t num_threads) {
+  if (num_threads < 0) {
+    return errors::InvalidArgument("`num_threads` must be >= 0");
+  }
+  if (num_threads >= kThreadLimit) {
+    return errors::InvalidArgument("`num_threads` must be < ", kThreadLimit);
+  }
+  return Status::OK();
+}
+}  // namespace
+
 class ThreadPoolResource : public ResourceBase {
  public:
   ThreadPoolResource(Env* env, const ThreadOptions& thread_options,
@@ -83,9 +99,7 @@ class ThreadPoolHandleOp : public OpKernel {
     OP_REQUIRES_OK(ctx, ctx->GetAttr("num_threads", &num_threads_));
     OP_REQUIRES_OK(ctx, ctx->GetAttr("max_intra_op_parallelism",
                                      &max_intra_op_parallelism_));
-    OP_REQUIRES(
-        ctx, num_threads_ > 0,
-        errors::InvalidArgument("`num_threads` must be greater than zero."));
+    OP_REQUIRES_OK(ctx, ValidateNumThreads(num_threads_));
   }
 
   // The resource is deleted from the resource manager only when it is private
@@ -531,8 +545,7 @@ void PrivateThreadPoolDatasetOp::MakeDatasetFromOptions(OpKernelContext* ctx,
                                                         DatasetBase* input,
                                                         int32_t num_threads,
                                                         DatasetBase** output) {
-  OP_REQUIRES(ctx, num_threads >= 0,
-              errors::InvalidArgument("`num_threads` must be >= 0"));
+  OP_REQUIRES_OK(ctx, ValidateNumThreads(num_threads));
   *output = new Dataset(ctx,
                         DatasetContext(DatasetContext::Params(
                             {PrivateThreadPoolDatasetOp::kDatasetType,
@@ -546,8 +559,7 @@ void PrivateThreadPoolDatasetOp::MakeDataset(OpKernelContext* ctx,
   int64_t num_threads = 0;
   OP_REQUIRES_OK(
       ctx, ParseScalarArgument<int64_t>(ctx, "num_threads", &num_threads));
-  OP_REQUIRES(ctx, num_threads >= 0,
-              errors::InvalidArgument("`num_threads` must be >= 0"));
+  OP_REQUIRES_OK(ctx, ValidateNumThreads(num_threads));
   *output = new Dataset(ctx, input, num_threads);
 }

Vulnerability mechanics

Generated on May 9, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.

References

7

News mentions

0

No linked articles in our index yet.