CVE-2021-29614: Interpreter crash from `tf.io.decode_raw`

Published May 14, 2021
·
Updated

Impact The implementation of tf.io.decoderaw produces incorrect results and crashes the Python interpreter when combining fixedlength and wider datatypes.

python import tensorflow as tf

tf.io.decoderaw(tf.constant(["1","2","3","4"]), tf.uint16, fixedlength=4) The implementation of the padded version is buggy due to a confusion about pointer arithmetic rules.

First, the code computes the width of each output element by dividing the fixedlength value to the size of the type argument:

cc int width = fixedlength / sizeof(T);

The fixedlength argument is also used to determine the size needed for the output tensor:

cc TensorShape outshape = input.shape(); outshape.AddDim(width); Tensor outputtensor = nullptr; OPREQUIRESOK(context, context->allocateoutput("output", outshape, &outputtensor));

auto out = outputtensor->flatinnerdims<T>(); T outdata = out.data(); memset(outdata, 0, fixedlength flatin.size());

This is followed by reencoding code:

cc for (int64 i = 0; i < flatin.size(); ++i) { const T indata = reinterpretcast<const T>(flatin(i).data());

if (flatin(i).size() > fixedlength) { memcpy(outdata, indata, fixedlength); } else { memcpy(outdata, indata, flatin(i).size()); } outdata += fixedlength; }

The erroneous code is the last line above: it is moving the outdata pointer by fixedlength sizeof(T) bytes whereas it only copied at most fixedlength bytes from the input. This results in parts of the input not being decoded into the output.

Furthermore, because the pointer advance is far wider than desired, this quickly leads to writing to outside the bounds of the backing data. This OOB write leads to interpreter crash in the reproducer mentioned here, but more severe attacks can be mounted too, given that this gadget allows writing to periodically placed locations in memory.

Patches We have patched the issue in GitHub commit 698e01511f62a3c185754db78ebce0eee1f0184d.

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.

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

Other sources

TensorFlow is an end-to-end open source platform for machine learning. The implementation of tf.io.decoderaw produces incorrect results and crashes the Python interpreter when combining fixedlength and wider datatypes. The implementation of the padded version(https://github.com/tensorflow/tensorflow/blob/1d8903e5b167ed0432077a3db6e462daf781d1fe/tensorflow/core/kernels/decodepaddedrawop.cc) is buggy due to a confusion about pointer arithmetic rules. First, the code computes(https://github.com/tensorflow/tensorflow/blob/1d8903e5b167ed0432077a3db6e462daf781d1fe/tensorflow/core/kernels/decodepaddedrawop.cc#L61) the width of each output element by dividing the fixedlength value to the size of the type argument. The fixedlength argument is also used to determine the size needed for the output tensor(https://github.com/tensorflow/tensorflow/blob/1d8903e5b167ed0432077a3db6e462daf781d1fe/tensorflow/core/kernels/decodepaddedrawop.cc#L63-L79). This is followed by reencoding code(https://github.com/tensorflow/tensorflow/blob/1d8903e5b167ed0432077a3db6e462daf781d1fe/tensorflow/core/kernels/decodepaddedrawop.cc#L85-L94). The erroneous code is the last line above: it is moving the outdata pointer by fixedlength sizeof(T) bytes whereas it only copied at most fixedlength bytes from the input. This results in parts of the input not being decoded into the output. Furthermore, because the pointer advance is far wider than desired, this quickly leads to writing to outside the bounds of the backing data. This OOB write leads to interpreter crash in the reproducer mentioned here, but more severe attacks can be mounted too, given that this gadget allows writing to periodically placed locations in memory. 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.

Affected Software

16 affected componentsFixes available
pip/tensorflow-gpu>=2.4.0<2.4.2
2.4.2
pip/tensorflow-gpu>=2.3.0<2.3.3
2.3.3
pip/tensorflow-gpu>=2.2.0<2.2.3
2.2.3
pip/tensorflow-gpu<2.1.4
2.1.4
pip/tensorflow-cpu>=2.4.0<2.4.2
2.4.2
pip/tensorflow-cpu>=2.3.0<2.3.3
2.3.3
pip/tensorflow-cpu>=2.2.0<2.2.3
2.2.3
pip/tensorflow-cpu<2.1.4
2.1.4
pip/tensorflow>=2.4.0<2.4.2
2.4.2
pip/tensorflow>=2.3.0<2.3.3
2.3.3
pip/tensorflow>=2.2.0<2.2.3
2.2.3
pip/tensorflow<2.1.4
2.1.4
Google TensorFlow<2.1.4
Google TensorFlow>=2.2.0<2.2.3
Google TensorFlow>=2.3.0<2.3.3
Google TensorFlow>=2.4.0<2.4.2

Event History

May 14, 2021
CVE Published
via MITRE·07:20 PM
Data Sourced
via MITRE·07:20 PM
DescriptionSeverityWeakness
May 21, 2021
Advisory Published
via GitHub·02:28 PM

Frequently Asked Questions

1

What is the severity of CVE-2021-29614?

CVE-2021-29614 has a medium severity due to its potential to crash the Python interpreter when improperly using the `tf.io.decode_raw` function.

2

How do I fix CVE-2021-29614?

To resolve CVE-2021-29614, upgrade TensorFlow to versions 2.4.2, 2.3.3, 2.2.3, or 2.1.4 as appropriate.

3

Which versions of TensorFlow are affected by CVE-2021-29614?

CVE-2021-29614 affects TensorFlow versions prior to 2.1.4 and between 2.2.0 and 2.4.2.

4

What impact does CVE-2021-29614 have on TensorFlow users?

CVE-2021-29614 can lead to incorrect results and crashes when using specific data types with `tf.io.decode_raw`.

5

Are all installations of TensorFlow vulnerable to CVE-2021-29614?

Not all installations are vulnerable; only those versions that are older than 2.1.4 or within specified ranges of 2.2.x, 2.3.x, and 2.4.x are affected.

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