aswin1906/github-advisory-2021.csv huggingface dataset:
Division by zero in `Conv3D`
Published: 2021-05-21T14:21:01Z
Aliases: CVE-2021-29517

### Impact
A malicious user could trigger a division by 0 in `Conv3D` implementation:

```python
import tensorflow as tf

input_tensor = tf.constant([], shape=[0, 0, 0, 0, 0], dtype=tf.float32)
filter_tensor = tf.constant([], shape=[0, 0, 0, 0, 0], dtype=tf.float32)

tf.raw_ops.Conv3D(input=input_tensor, filter=filter_tensor, strides=[1, 56, 56, 56, 1], padding='VALID', data_format='NDHWC', dilations=[1, 1, 1, 23, 1])
```

The [implementation](https://github.com/tensorflow/tensorflow/blob/42033603003965bffac51ae171b51801565e002d/tensorflow/core/kernels/conv_ops_3d.cc#L143-L145) does a modulo operation based on user controlled input:

```cc
  const int64 out_depth = filter.dim_size(4);
  OP_REQUIRES(context, in_depth % filter_depth == 0, ...);
```

Thus, when `filter` has a 0 as the fifth element, this results in a division by 0.

Additionally, if the shape of the two tensors is not valid, an Eigen assertion can be triggered, resulting in a program crash:

```python
import tensorflow as tf

input_tensor = tf.constant([], shape=[2, 2, 2, 2, 0], dtype=tf.float32)
filter_tensor = tf.constant([], shape=[0, 0, 2, 6, 2], dtype=tf.float32)

tf.raw_ops.Conv3D(input=input_tensor, filter=filter_tensor, strides=[1, 56, 39, 34, 1], padding='VALID', data_format='NDHWC', dilations=[1, 1, 1, 1, 1])
```

The shape of the two tensors must follow the constraints specified in the [op description](https://www.tensorflow.org/api_docs/python/tf/raw_ops/Conv3D).

### Patches
We have patched the issue in GitHub commit [799f835a3dfa00a4d852defa29b15841eea9d64f](https://github.com/tensorflow/tensorflow/commit/799f835a3dfa00a4d852defa29b15841eea9d64f).

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](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 reported by Yakun Zhang and Ying Wang of Baidu X-Team.
Heap OOB read in TFLite's implementation of `Minimum` or `Maximum`
Published: 2021-05-21T14:26:53Z
Aliases: CVE-2021-29590

### Impact
The implementations of the `Minimum` and `Maximum` TFLite operators can be used to read data outside of bounds of heap allocated objects, if any of the two input tensor arguments are empty.

This is because [the broadcasting implementation](https://github.com/tensorflow/tensorflow/blob/0d45ea1ca641b21b73bcf9c00e0179cda284e7e7/tensorflow/lite/kernels/internal/reference/maximum_minimum.h#L52-L56) indexes in both tensors with the same index but does not validate that the index is within bounds:

```cc
auto maxmin_func = [&](int indexes[N]) {
  output_data[SubscriptToIndex(output_desc, indexes)] =
    op(input1_data[SubscriptToIndex(desc1, indexes)],
        input2_data[SubscriptToIndex(desc2, indexes)]);
};
```

### Patches
We have patched the issue in GitHub commit [953f28dca13c92839ba389c055587cfe6c723578](https://github.com/tensorflow/tensorflow/commit/953f28dca13c92839ba389c055587cfe6c723578).

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](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 reported by members of the Aivul Team from Qihoo 360.
XStream is vulnerable to a Remote Command Execution attack
Published: 2021-05-18T18:36:27Z
Aliases: CVE-2021-29505

### Impact
The vulnerability may allow a remote attacker has sufficient rights to execute commands of the host only by manipulating the processed input stream. No user is affected, who followed the recommendation to setup XStream's security framework with a whitelist limited to the minimal required types.

### Patches
If you rely on XStream's default blacklist of the Security Framework, you will have to use at least version 1.4.17.

### Workarounds
See [workarounds](https://x-stream.github.io/security.html#workaround) for the different versions covering all CVEs.

### References
See full information about the nature of the vulnerability and the steps to reproduce it in XStream's documentation for [CVE-2021-29505](https://x-stream.github.io/CVE-2021-29505.html).

### Credits

V3geB1rd, white hat hacker from Tencent Security Response Center found and reported the issue to XStream and provided the required information to reproduce it.

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [XStream](https://github.com/x-stream/xstream/issues)
* Email us at [XStream Google Group](https://groups.google.com/group/xstream-user)
Division by 0 in `QuantizedConv2D`
Published: 2021-05-21T14:21:59Z
Aliases: CVE-2021-29527

### Impact
An attacker can trigger a division by 0 in `tf.raw_ops.QuantizedConv2D`:

```python
import tensorflow as tf

input = tf.zeros([1, 1, 1, 1], dtype=tf.quint8)
filter = tf.constant([], shape=[1, 0, 1, 1], dtype=tf.quint8)
min_input = tf.constant(0.0)
max_input = tf.constant(0.0001)
min_filter = tf.constant(0.0)
max_filter = tf.constant(0.0001)
strides = [1, 1, 1, 1]
padding = "SAME"               
                               

tf.raw_ops.QuantizedConv2D(input=input, filter=filter, min_input=min_input, max_input=max_input, min_filter=min_filter, max_filter=max_filter, strides=strides, padding=padding)
```
This is because the [implementation](https://github.com/tensorflow/tensorflow/blob/00e9a4d67d76703fa1aee33dac582acf317e0e81/tensorflow/core/kernels/quantized_conv_ops.cc#L257-L259) does a division by a quantity that is controlled by the caller: 

```cc
const int filter_value_count = filter_width * filter_height * input_depth;
const int64 patches_per_chunk = kMaxChunkSize / (filter_value_count * sizeof(T1));
```
  
### Patches
We have patched the issue in GitHub commit [cfa91be9863a91d5105a3b4941096044ab32036b](https://github.com/tensorflow/tensorflow/commit/cfa91be9863a91d5105a3b4941096044ab32036b).

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](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 reported by Ying Wang and Yakun Zhang of Baidu X-Team.
Private Field data leak
Published: 2021-05-27T18:39:03Z
Aliases: CVE-2021-32624

This security advisory relates to a newly discovered capability in our query infrastructure to directly or indirectly expose the values of private fields, bypassing the configured access control.

This is an access control related oracle attack in that the attack method guides an attacker during their attempt to reveal information they do not have access to. The complexity of completing the attack is limited by some length-dependent behaviors and the fidelity of the exposed information.

### Impact

Under some circumstances, field values or field value meta data can be determined, despite the field or list having `read` access control configured. If you use private fields or lists, you may be impacted.

### Patches

None, at this time

### Workarounds

None, at this time

### References

None

### For more information

For the protection of the community and private deployments, we think that the best course of action will be to not disclose further details on any open GitHub issues related to this advisory until a hot-fix or work-around has been deployed or published.

If needed, you can email us at keystone@thinkmill.com.au
Regular expression Denial of Service (ReDoS) in EmailValidator class in V7 compatibility module in Vaadin 8
Published: 2021-05-04T17:42:02Z
Aliases: CVE-2021-31409

Unsafe validation RegEx in `EmailValidator` component in `com.vaadin:vaadin-compatibility-server` versions 8.0.0 through 8.12.4 (Vaadin versions 8.0.0 through 8.12.4) allows attackers to cause uncontrolled resource consumption by submitting malicious email addresses.
Heap buffer overflow in `QuantizedReshape`
Published: 2021-05-21T14:22:32Z
Aliases: CVE-2021-29536

### Impact
An attacker can cause a heap buffer overflow in `QuantizedReshape` by passing in invalid thresholds for the quantization:

```python
import tensorflow as tf

tensor = tf.constant([], dtype=tf.qint32)
shape = tf.constant([], dtype=tf.int32)
input_min = tf.constant([], dtype=tf.float32)
input_max = tf.constant([], dtype=tf.float32)

tf.raw_ops.QuantizedReshape(tensor=tensor, shape=shape, input_min=input_min, input_max=input_max)
```

This is because the [implementation](https://github.com/tensorflow/tensorflow/blob/a324ac84e573fba362a5e53d4e74d5de6729933e/tensorflow/core/kernels/quantized_reshape_op.cc#L38-L55) assumes that the 2 arguments are always valid scalars and tries to access the numeric value directly:

```cc
const auto& input_min_float_tensor = ctx->input(2);
...
const float input_min_float = input_min_float_tensor.flat<float>()(0);
const auto& input_max_float_tensor = ctx->input(3);
...
const float input_max_float = input_max_float_tensor.flat<float>()(0);
```

However, if any of these tensors is empty, then `.flat<T>()` is an empty buffer and accessing the element at position 0 results in overflow.

### Patches
We have patched the issue in GitHub commit [a324ac84e573fba362a5e53d4e74d5de6729933e](https://github.com/tensorflow/tensorflow/commit/a324ac84e573fba362a5e53d4e74d5de6729933e).

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](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 reported by Ying Wang and Yakun Zhang of Baidu X-Team.
OAuth2 Redirect URL validity does not respect query parameters and character casing for loopback addresses
Published: 2021-05-24T17:00:12Z
Aliases: CVE-2020-15233

### Impact

[fosite#400](https://github.com/ory/fosite/pull/400) (released as v0.30.2) introduced a new feature for handling redirect URLs pointing to loopback interfaces ([rfc8252#section-7.3](https://tools.ietf.org/html/rfc8252#section-7.3)). As part of that change new behavior was introduced which failed to respect the redirect URL's (only for loopback interfaces!) query parameters

1. Registering a client with allowed redirect URL `http://127.0.0.1/callback`
2. Performing OAuth2 flow and requesting redirect URL `http://127.0.0.1/callback?bar=foo`
3. Instead of an error, the browser is redirected to `http://127.0.0.1/callback?bar=foo` with a potentially successful OAuth2 response.

as well as the host parameter (as long as the host is a loopback interface):

1. Registering a client with allowed redirect URL `https://example.com/callback`
2. Performing OAuth2 flow and requesting redirect URL `http://127.0.0.1/callback`
3. Instead of an error, the browser is redirected to `http://127.0.0.1/callback` with a potentially successful OAuth2 response.

These bugs are only applicable in scenarios where the attacker has control over the loopback interface (`localhost`, `127.0.0.1`, `[::1]`) where the browser performing the OAuth2 flow is running.
Cross-site scripting in TileServer GL
Published: 2021-05-17T21:01:15Z
Aliases: CVE-2020-15500

An issue was discovered in server.js in TileServer GL through 3.0.0. The content of the key GET parameter is reflected unsanitized in an HTTP response for the application's main page, causing reflected XSS.
Deserialization of Untrusted Data in Apache Camel RabbitMQ
Published: 2021-05-21T19:20:47Z
Aliases: CVE-2020-11972

Apache Camel RabbitMQ enables Java deserialization by default. Apache Camel 2.22.x, 2.23.x, 2.24.x, 2.25.0, 3.0.0 up to 3.1.0 are affected. 2.x users should upgrade to 2.25.1, 3.x users should upgrade to 3.2.0.
SQL Injection in odata4j
Published: 2021-05-07T15:52:41Z
Aliases: CVE-2016-11024

odata4j 0.7.0 allows ExecuteJPQLQueryCommand.java SQL injection. NOTE: this product is apparently discontinued.
Denial of service (via resource exhaustion) due to improper input validation in third-party identifier endpoint
Published: 2021-05-19T23:01:45Z

### Impact
Missing input validation of some parameters on the endpoints used to confirm third-party identifiers could cause excessive use of disk space and memory leading to resource exhaustion.

### Patches
The issue is fixed by https://github.com/matrix-org/synapse/pull/9855.

### Workarounds
There are no known workarounds.

### References
n/a

### For more information
If you have any questions or comments about this advisory, email us at security@matrix.org.
Regular expression denial of service in @absolunet/kafe
Published: 2021-05-10T19:08:29Z
Aliases: CVE-2020-7761

This affects the package @absolunet/kafe before 3.2.10. It allows cause a denial of service when validating crafted invalid emails.
XML Entity Expansion and Improper Input Validation in Kubernetes API server
Published: 2021-05-18T15:38:48Z
Aliases: CVE-2019-11253

Improper input validation in the Kubernetes API server in versions v1.0-1.12 and versions prior to v1.13.12, v1.14.8, v1.15.5, and v1.16.2 allows authorized users to send malicious YAML or JSON payloads, causing the API server to consume excessive CPU or memory, potentially crashing and becoming unavailable. Prior to v1.14.0, default RBAC policy authorized anonymous users to submit requests that could trigger this vulnerability. Clusters upgraded from a version prior to v1.14.0 keep the more permissive policy by default for backwards compatibility.

### Specific Go Packages Affected
k8s.io/kubernetes/pkg/apiserver
Null pointer dereference via invalid Ragged Tensors
Published: 2021-05-21T14:20:58Z
Aliases: CVE-2021-29516

### Impact
Calling `tf.raw_ops.RaggedTensorToVariant` with arguments specifying an invalid ragged tensor results in a null pointer dereference:

```python
import tensorflow as tf

input_tensor = tf.constant([], shape=[0, 0, 0, 0, 0], dtype=tf.float32)
filter_tensor = tf.constant([], shape=[0, 0, 0, 0, 0], dtype=tf.float32)

tf.raw_ops.Conv3D(input=input_tensor, filter=filter_tensor, strides=[1, 56, 56, 56, 1], padding='VALID', data_format='NDHWC', dilations=[1, 1, 1, 23, 1])
```

```python
import tensorflow as tf

input_tensor = tf.constant([], shape=[2, 2, 2, 2, 0], dtype=tf.float32)
filter_tensor = tf.constant([], shape=[0, 0, 2, 6, 2], dtype=tf.float32)

tf.raw_ops.Conv3D(input=input_tensor, filter=filter_tensor, strides=[1, 56, 39, 34, 1], padding='VALID', data_format='NDHWC', dilations=[1, 1, 1, 1, 1])
```

The implementation of [`RaggedTensorToVariant` operations](https://github.com/tensorflow/tensorflow/blob/904b3926ed1c6c70380d5313d282d248a776baa1/tensorflow/core/kernels/ragged_tensor_to_variant_op.cc#L39-L40) does not validate that the ragged tensor argument is non-empty:

```cc
  int ragged_rank = batched_ragged.ragged_rank();
  auto batched_splits_top_vec = batched_ragged.splits(0).vec<SPLIT_TYPE>();
```

Since `batched_ragged` contains no elements, `batched_ragged.splits` is a null vector, thus `batched_ragged.splits(0)` will result in  dereferencing `nullptr`.

### Patches
We have patched the issue in GitHub commit [b055b9c474cd376259dde8779908f9eeaf097d93](https://github.com/tensorflow/tensorflow/commit/b055b9c474cd376259dde8779908f9eeaf097d93).

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](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 reported by Yakun Zhang and Ying Wang of Baidu X-Team.
Cross-site scripting in @shopify/koa-shopify-auth
Published: 2021-05-17T21:01:22Z
Aliases: CVE-2020-8176

A cross-site scripting vulnerability exists in koa-shopify-auth v3.1.61-v3.1.62 that allows an attacker to inject JS payloads into the `shop` parameter on the `/shopify/auth/enable_cookies` endpoint.
Prototype pollution in json-pointer
Published: 2021-05-10T18:37:47Z
Aliases: CVE-2020-7709

This affects the package json-pointer before 0.6.1. Multiple reference of object using slash is supported.
Arbitrary Code Execution in underscore
Published: 2021-05-06T16:09:43Z
Aliases: CVE-2021-23358

The package `underscore` from 1.13.0-0 and before 1.13.0-2, from 1.3.2 and before 1.12.1 are vulnerable to Arbitrary Code Execution via the template function, particularly when a variable property is passed as an argument as it is not sanitized.
Cross-site scripting in bluemonday
Published: 2021-05-18T21:07:37Z
Aliases: CVE-2021-29272

bluemonday before 1.0.5 allows XSS because certain Go lowercasing converts an uppercase Cyrillic character, defeating a protection mechanism against the "script" string.
Improper Neutralization of Special Elements used in a Command ('Command Injection') in @floffah/build
Published: 2021-05-28T15:53:40Z

### Impact
If you are using the esbuild target or command you are at risk of code/option injection. Attackers can use the command line option to maliciously change your settings in order to damage your project.

### Patches
The problem has been patched in v1.0.0 as it uses a proper method to pass configs to esbuild/estrella.

### Workarounds
There is no work around. You should update asap.

### Notes
This notice is mainly just to make sure people update to the latest version. This isn't that bad, but should encourage you to update.
Heap buffer overflow in `SparseTensorToCSRSparseMatrix`
Published: 2021-05-21T14:23:25Z
Aliases: CVE-2021-29545

### Impact
An attacker can trigger a denial of service via a `CHECK`-fail in converting sparse tensors to CSR Sparse matrices:

```python
import tensorflow as tf
import numpy as np
from tensorflow.python.ops.linalg.sparse import sparse_csr_matrix_ops

indices_array = np.array([[0, 0]])
value_array = np.array([0.0], dtype=np.float32)
dense_shape = [0, 0]

st = tf.SparseTensor(indices_array, value_array, dense_shape)

values_tensor = sparse_csr_matrix_ops.sparse_tensor_to_csr_sparse_matrix(
       st.indices, st.values, st.dense_shape)
```

This is because the [implementation](https://github.com/tensorflow/tensorflow/blob/800346f2c03a27e182dd4fba48295f65e7790739/tensorflow/core/kernels/sparse/kernels.cc#L66) does a double redirection to access an element of an array allocated on the heap:

```cc
csr_row_ptr(indices(i, 0) + 1) += 1;
```
                      
If the value at `indices(i, 0)` is such that `indices(i, 0) + 1` is outside the bounds of `csr_row_ptr`, this results in writing outside of bounds of heap allocated data.

### Patches
We have patched the issue in GitHub commit [1e922ccdf6bf46a3a52641f99fd47d54c1decd13](https://github.com/tensorflow/tensorflow/commit/1e922ccdf6bf46a3a52641f99fd47d54c1decd13).

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](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 reported by Yakun Zhang and Ying Wang of Baidu X-Team.
Arbitrary code execution due to an uncontrolled search path for the git binary
Published: 2021-05-25T18:44:09Z
Aliases: CVE-2021-28955

### Impact

The go language recently addressed a security issue in the way that binaries are found before being executed. Some operating systems like Windows persist to have the current directory being part of the default search path, and having priority over the system-wide path.

This means that it's possible for a malicious user to craft for example a `git.bat` command, commit it and push it in a repository. Later when git-bug search for the git binary, this malicious executable can take priority  and be executed.

### Who is impacted

This issue happen on Windows and some other operating systems with a badly configured PATH.

All version prior to 0.7.2 are vulnerable to this issue.

### Patches

Version 0.7.2 fix this issue. Users should update as soon as possible.

### References

More details about this issue can be found [here](https://blog.golang.org/path-security).
Insecure permissions on build temporary rootfs in Singularity
Published: 2021-05-24T16:56:23Z
Aliases: CVE-2020-25040

### Impact

Insecure permissions on temporary directories used in explicit and implicit container build operations.

When a Singularity command that results in a container build operation is executed, it is possible for a user with access to the system to read the contents of the image during the build. Additionally, if the image contains a world-writable file or directory, it is possible for a user to inject arbitrary content into the running build, which in certain circumstances may enable arbitrary code execution during the build and/or when the built container is run.

### Patches

This issue is addressed in Singularity 3.6.3.

All users are advised to upgrade to 3.6.3.

### Workarounds

The issue is mitigated if `TMPDIR` is set to a location that is only accessible to the user, as any subdirectories directly under `TMPDIR` cannot then be accessed by others. However, this is difficult to enforce so it is not recommended to rely on this as a mitigation.

### For more information

General questions about the impact of the advisory / changes made in the 3.6.0 release can be asked in the:

* [Singularity Slack Channel](https://bit.ly/2m0g3lX)
* [Singularity Mailing List](https://groups.google.com/a/lbl.gov/forum/??sdf%7Csort:date#!forum/singularity)

Any sensitive security concerns should be directed to: security@sylabs.io

See our Security Policy here: https://sylabs.io/security-policy
github.com/russellhaering/goxmldsig vulnerable to Signature Validation Bypass
Published: 2021-05-24T16:57:32Z
Aliases: CVE-2020-15216

### Impact
With a carefully crafted XML file, an attacker can completely bypass signature validation and pass off an altered file as a signed one. 

### Patches
A patch is available, all users of goxmldsig should upgrade to v1.1.0.

### For more information
If you have any questions or comments about this advisory open an issue at https://github.com/russellhaering/goxmldsig
Path Traversal in Buildah
Published: 2021-05-18T18:32:41Z
Aliases: CVE-2020-10696

A path traversal flaw was found in Buildah in versions before 1.14.5. This flaw allows an attacker to trick a user into building a malicious container image hosted on an HTTP(s) server and then write files to the user's system anywhere that the user has permissions.

### Specific Go Packages Affected
github.com/containers/buildah/imagebuildah
Improper certificate validation in em-imap
Published: 2021-05-24T18:12:20Z
Aliases: CVE-2020-13163

em-imap 0.5 and earlier use the library eventmachine in an insecure way that allows an attacker to perform a man-in-the-middle attack against users of the library. The hostname in a TLS server certificate is not verified.