In Tensorflow before versions 2.2.1 and 2.3.1, if a user passes an invalid argument to `dlpack.to_dlpack` the expected validations will…
GitHub_M·CWE-20·Published 2020-09-25
In Tensorflow before versions 2.2.1 and 2.3.1, if a user passes an invalid argument to `dlpack.to_dlpack` the expected validations will cause variables to bind to `nullptr` while setting a `status` variable to the error condition. However, this `status` argument is not properly checked. Hence, code following these methods will bind references to null pointers. This is undefined behavior and reported as an error if compiling with `-fsanitize=null`. The issue is patched in commit 22e07fb204386768e5bcbea563641ea11f96ceb8 and is released in TensorFlow versions 2.2.1, or 2.3.1.
In Tensorflow before versions 2.2.1 and 2.3.1, if a user passes an invalid argument to `dlpack.to_dlpack` the expected validations will cause variables to bind to `nullptr` while setting a `status` variable to the error condition. However, this `status` argument is not properly checked. Hence, code following these methods will bind references to null pointers. This is undefined behavior and reported as an error if compiling with `-fsanitize=null`. The issue is patched in commit 22e07fb204386768e5bcbea563641ea11f96ceb8 and is released in TensorFlow versions 2.2.1, or 2.3.1.
In Tensorflow before versions 2.2.1 and 2.3.1, if a user passes an invalid argument to `dlpack.to_dlpack` the expected validations will cause variables to bind to `nullptr` while setting a `status` variable to the error condition. However, this `status` argument is not properly checked. Hence, code following these methods will bind references to null pointers. This is undefined behavior and reported as an error if compiling with `-fsanitize=null`. The issue is patched in commit 22e07fb204386768e5bcbea563641ea11f96ceb8 and is released in TensorFlow versions 2.2.1, or 2.3.1.
### Impact If a user passes an invalid argument to `dlpack.to_dlpack` the expected validations will cause variables to bind to `nullptr` while setting a `status` variable to the error condition. However, this `status` argument is not properly checked: https://github.com/tensorflow/tensorflow/blob/0e68f4d3295eb0281a517c3662f6698992b7b2cf/tensorflow/c/eager/dlpack.cc#L265-L267 Hence, code following these methods will bind references to null pointers: https://github.com/tensorflow/tensorflow/blob/0e68f4d3295eb0281a517c3662f6698992b7b2cf/tensorflow/c/eager/dlpack.cc#L279-L285 This is undefined behavior and reported as an error if compiling with `-fsanitize=null`. ### Patches We have patched the issue in 22e07fb204386768e5bcbea563641ea11f96ceb8 and will release a patch release for all affected versions. We recommend users to upgrade to TensorFlow 2.2.1 or 2.3.1. ### For more information Please consult [our security guide](https://github.com/tensorflow/tensorflow/blob/master/SECURITY.md) for more information regarding the security model and how to contact us with issues and questions. ### Attribution This vulnerability has been discovered during variant analysis of [GHSA-rjjg-hgv6-h69v](https://github.com/tensorflow/tensorflow/security/advisories/GHSA-rjjg-hgv6-h69v).
En Tensorflow versiones anteriores a 2.2.1 y 2.3.1, si un usuario pasa un argumento no válido hacia "dlpack.to_dlpack", las comprobaciones previstas harán que las variables se unan a "nullptr" mientras se establece una variable "status" para la condición de error. Sin embargo, este argumento "status" no se comprueba correctamente. Por lo tanto, el código que sigue estos métodos vinculará referencias a punteros null. Este es un comportamiento indefinido y se reporta como un error si se compila con "-fsanitize=null". El problema es parcheado en el commit 22e07fb204386768e5bcbea563641ea11f96ceb8 y es publicado en TensorFlow versiones 2.2.1 o 2.3.1
| Version | Type | Source | Base | Exp | Impact | Vector |
|---|---|---|---|---|---|---|
| 2.0 | Primary | NVD | 5.0 | 10.0 | 2.9 | AV:N/AC:L/Au:N/C:N/I:N/A:P |
| 3.1 | Primary | cve.org | 5.3 | — | — | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L |
| 3.1 | Primary | cve.org | 5.3 | — | — | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L |
| 3.1 | Primary | NVD | 5.3 | 3.9 | 1.4 | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L |
| 3.1 | Secondary | GHSA | 5.3 | — | — | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L |
| 3.1 | Secondary | NVD | 5.3 | 3.9 | 1.4 | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L |
| 4.0 | Secondary | GHSA | 6.9 | — | — | CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N |