CVE-2020-15211: Out of bounds access in tensorflow-lite

Published Sep 25, 2020
·
Updated

Impact In TensorFlow Lite, saved models in the flatbuffer format use a double indexing scheme: a model has a set of subgraphs, each subgraph has a set of operators and each operator has a set of input/output tensors. The flatbuffer format uses indices for the tensors, indexing into an array of tensors that is owned by the subgraph. This results in a pattern of double array indexing when trying to get the data of each tensor: https://github.com/tensorflow/tensorflow/blob/0e68f4d3295eb0281a517c3662f6698992b7b2cf/tensorflow/lite/kernels/kernelutil.cc#L36

However, some operators can have some tensors be optional. To handle this scenario, the flatbuffer model uses a negative -1 value as index for these tensors: https://github.com/tensorflow/tensorflow/blob/0e68f4d3295eb0281a517c3662f6698992b7b2cf/tensorflow/lite/c/common.h#L82

This results in special casing during validation at model loading time: https://github.com/tensorflow/tensorflow/blob/0e68f4d3295eb0281a517c3662f6698992b7b2cf/tensorflow/lite/core/subgraph.cc#L566-L580

Unfortunately, this means that the -1 index is a valid tensor index for any operator, including those that don't expect optional inputs and including for output tensors. Thus, this allows writing and reading from outside the bounds of heap allocated arrays, although only at a specific offset from the start of these arrays.

This results in both read and write gadgets, albeit very limited in scope.

Patches We have patched the issue in several commits (46d5b0852, 00302787b7, e11f5558, cd31fd0ce, 1970c21, and fff2c83). We will release patch releases for all versions between 1.15 and 2.3.

We recommend users to upgrade to TensorFlow 1.15.4, 2.0.3, 2.1.2, 2.2.1, or 2.3.1.

Workarounds A potential workaround would be to add a custom Verifier to the model loading code to ensure that only operators which accept optional inputs use the -1 special value and only for the tensors that they expect to be optional. Since this allow-list type approach is erro-prone, we advise upgrading to the patched code.

For more information Please consult our security guide for more information regarding the security model and how to contact us with issues and questions.

Attribution This vulnerability has been reported by members of the Aivul Team from Qihoo 360.

Other sources

In TensorFlow Lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, saved models in the flatbuffer format use a double indexing scheme: a model has a set of subgraphs, each subgraph has a set of operators and each operator has a set of input/output tensors. The flatbuffer format uses indices for the tensors, indexing into an array of tensors that is owned by the subgraph. This results in a pattern of double array indexing when trying to get the data of each tensor. However, some operators can have some tensors be optional. To handle this scenario, the flatbuffer model uses a negative -1 value as index for these tensors. This results in special casing during validation at model loading time. Unfortunately, this means that the -1 index is a valid tensor index for any operator, including those that don't expect optional inputs and including for output tensors. Thus, this allows writing and reading from outside the bounds of heap allocated arrays, although only at a specific offset from the start of these arrays. This results in both read and write gadgets, albeit very limited in scope. The issue is patched in several commits (46d5b0852, 00302787b7, e11f5558, cd31fd0ce, 1970c21, and fff2c83), and is released in TensorFlow versions 1.15.4, 2.0.3, 2.1.2, 2.2.1, or 2.3.1. A potential workaround would be to add a custom Verifier to the model loading code to ensure that only operators which accept optional inputs use the -1 special value and only for the tensors that they expect to be optional. Since this allow-list type approach is erro-prone, we advise upgrading to the patched code.

Affected Software

21 affected componentsFixes available
pip/tensorflow-gpu=2.3.0
2.3.1
pip/tensorflow-gpu=2.2.0
2.2.1
pip/tensorflow-gpu>=2.1.0<2.1.2
2.1.2
pip/tensorflow-gpu>=2.0.0<2.0.3
2.0.3
pip/tensorflow-gpu<1.15.4
1.15.4
pip/tensorflow-cpu=2.3.0
2.3.1
pip/tensorflow-cpu=2.2.0
2.2.1
pip/tensorflow-cpu>=2.1.0<2.1.2
2.1.2
pip/tensorflow-cpu>=2.0.0<2.0.3
2.0.3
pip/tensorflow-cpu<1.15.4
1.15.4
pip/tensorflow=2.3.0
2.3.1
pip/tensorflow=2.2.0
2.2.1
pip/tensorflow>=2.1.0<2.1.2
2.1.2
pip/tensorflow>=2.0.0<2.0.3
2.0.3
pip/tensorflow<1.15.4
1.15.4
Google TensorFlow<1.15.4
Google TensorFlow>=2.0.0<2.0.3
Google TensorFlow>=2.1.0<2.1.2
Google TensorFlow>=2.2.0<2.2.1
Google TensorFlow>=2.3.0<2.3.1
openSUSE Leap=15.2

Event History

Sep 25, 2020
Advisory Published
via GitHub·06:28 PM
CVE Published
via MITRE·06:45 PM
Data Sourced
via MITRE·06:45 PM
DescriptionSeverityWeakness

Frequently Asked Questions

1

What is the severity of CVE-2020-15211?

The severity of CVE-2020-15211 is classified as high due to potential memory access vulnerabilities in TensorFlow Lite.

2

How do I fix CVE-2020-15211?

To fix CVE-2020-15211, upgrade to TensorFlow versions 2.3.1, 2.2.1, 2.1.2, or 2.0.3 depending on your installation.

3

Which versions of TensorFlow are affected by CVE-2020-15211?

CVE-2020-15211 affects TensorFlow versions 2.3.0 and earlier, as well as 2.2.0, 2.1.0, 2.0.0, and all versions prior to 1.15.4.

4

Is CVE-2020-15211 present in TensorFlow Lite?

Yes, CVE-2020-15211 specifically affects TensorFlow Lite by exploiting the double indexing scheme in saved models.

5

What are the potential impacts of CVE-2020-15211?

CVE-2020-15211 can lead to memory corruption, which may allow an attacker to execute arbitrary code or cause a denial of service.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203