GHSA-mw6j-hh29-h379

What it actually does

This vulnerability is a TensorFlow denial-of-service flaw in depthwise operation handling. Crafted tensor shapes, convolution parameters, or model graph inputs can trigger integer overflows in TensorFlow depthwise operations, causing an internal CHECK assertion failure. In affected versions of the tensorflow PyPI package, this typically terminates the process rather than safely rejecting the invalid operation. The expected impact is process crash and service interruption, not code execution or data disclosure based on the available advisory information.

Why it matters to the business

Systems that run TensorFlow on untrusted or externally influenced models, tensors, or inference requests can be crashed by malformed input, disrupting ML inference, batch processing, model validation, or data-processing pipelines. The issue is not listed in CISA KEV, has no reported exploit maturity in the provided data, and was published in 2022, so urgency is highest for internet-facing or multi-tenant ML services and lower for isolated workloads that only process trusted models and data.

How an attack unfolds

An attacker needs a path to influence TensorFlow execution, such as submitting an ML model, supplying serialized tensors, controlling image or feature dimensions that become tensor shapes, or interacting with an inference endpoint that accepts user-controlled inputs. The attacker crafts inputs or graph parameters that cause depthwise convolution-related calculations to overflow internal size or shape computations. When TensorFlow evaluates the operation, the overflowed state violates an internal CHECK condition. Instead of returning a controlled validation error, the affected TensorFlow runtime aborts the process. If the vulnerable runtime backs an API, model-serving worker, notebook service, or batch job, exploitation results in worker crashes, failed requests, job termination, and possible repeated service disruption if the payload is replayed.

How to fix it

Upgrade the tensorflow PyPI package to a fixed version. The provided fixed version is tensorflow 2.6.4; where possible, upgrade to 2.6.4 or a later supported TensorFlow release that includes the fix. Rebuild and redeploy containers, virtual environments, notebooks, model-serving images, and batch-processing runtimes that bundle TensorFlow. If immediate upgrade is not possible, reduce exposure by rejecting untrusted models, validating tensor shapes and convolution parameters before execution, applying strict input size limits, isolating TensorFlow execution in restartable sandboxes, and using queue/rate controls to prevent repeated crash loops from exhausting capacity.

How to confirm the fix worked

Confirm that all deployed Python environments and container images use a fixed TensorFlow version by checking package inventories, lockfiles, SBOMs, and runtime output such as `pip show tensorflow` or `python -c "import tensorflow as tf; print(tf.__version__)"`. Verify that no production image, notebook kernel, or model-serving runtime still includes an affected tensorflow build. After upgrading, run regression tests for workloads using depthwise convolution operations and confirm malformed or oversized inputs are rejected gracefully rather than terminating the process. Validate operationally by confirming that service workers remain stable under invalid-input tests and that container or process restart counts do not increase.

Typical attack path

1. Identify an application, API, notebook, pipeline, or model-serving endpoint that uses an affected tensorflow PyPI version.
2. Find a way to influence TensorFlow tensors, model graphs, convolution parameters, image dimensions, or serialized model/input content.
3. Craft malformed depthwise-operation input with dimensions or parameters intended to trigger integer overflow in TensorFlow internal calculations.
4. Submit the crafted input or model to the vulnerable service or processing pipeline.
5. TensorFlow evaluates the depthwise operation, hits a CHECK failure, and aborts the process.
6. Repeat submissions to keep workers, jobs, or serving instances unavailable until the service is patched or input validation blocks the payload.

How to detect it

Look for evidence of process crashes or repeated worker restarts correlated with TensorFlow depthwise operations or unusual model/input submissions. Relevant sources include application logs, model-serving logs, API gateway logs, container stdout/stderr, Kubernetes events, systemd or supervisor logs, crash dumps, Python exception logs, and workload scheduler logs. Indicators include TensorFlow fatal CHECK failures, SIGABRT events, core dumps from Python or TensorFlow-serving processes, sudden spikes in 5xx responses or inference timeouts, and repeated requests containing unusually large or malformed tensor/image dimensions shortly before crashes. If model upload or serialized input is supported, review submissions immediately preceding the crash for depthwise convolution operations and abnormal shape parameters. Because this is a denial-of-service bug rather than a persistent compromise technique, absence of files or persistence artifacts does not rule out exploitation; focus on runtime crash telemetry and request/model history.

• Check failed:
• CHECK failure
• DepthwiseConv2dNative
• DepthwiseConv2dNativeBackpropInput
• DepthwiseConv2dNativeBackpropFilter
• depthwise
• SIGABRT
• Aborted (core dumped)
• tensorflow/core/kernels/depthwise_conv_op
• Fatal Python error
• core dumped

What your security team should do

• Inventory all uses of the tensorflow PyPI package across applications, containers, notebooks, ML serving platforms, CI jobs, and batch-processing environments.
• Prioritize upgrades for internet-facing, user-facing, or multi-tenant systems that process untrusted models or untrusted tensor/input data.
• Upgrade tensorflow to 2.6.4 or a later supported fixed release and rebuild all dependent artifacts rather than only changing source dependency files.
• Add input validation for tensor dimensions, image sizes, convolution parameters, and model upload workflows before data reaches TensorFlow execution.
• Block or quarantine untrusted model files unless they are scanned, validated, and executed in a sandboxed environment.
• Add monitoring for TensorFlow process aborts, CHECK failures, core dumps, container restarts, and repeated failed inference requests.
• For services that cannot be patched immediately, isolate vulnerable workers, apply request size limits and rate limits, and ensure supervisors restart crashed workers without causing cascading outages.