aswin1906/github-advisory-2021.csv huggingface dataset:
Improper Handling of Exceptional Conditions in Apache Tomcat
Published: 2021-08-13T15:21:02Z
Aliases: CVE-2021-30639

A vulnerability in Apache Tomcat allows an attacker to remotely trigger a denial of service. An error introduced as part of a change to improve error handling during non-blocking I/O meant that the error flag associated with the Request object was not reset between requests. This meant that once a non-blocking I/O error occurred, all future requests handled by that request object would fail. Users were able to trigger non-blocking I/O errors, e.g. by dropping a connection, thereby creating the possibility of triggering a DoS. Applications that do not use non-blocking I/O are not exposed to this vulnerability. This issue affects Apache Tomcat 10.0.3 to 10.0.4; 9.0.44; 8.5.64.
Insufficient size checks in ws
Published: 2021-08-25T20:49:32Z
Aliases: CVE-2020-35896

An issue was discovered in the ws crate through 2020-09-25 for Rust. The outgoing buffer is not properly limited, leading to a remote memory-consumption attack.
Data races in rusqlite
Published: 2021-08-25T20:47:59Z
Aliases: CVE-2020-35866

An issue was discovered in the rusqlite crate before 0.23.0 for Rust. Memory safety can be violated via VTab / VTabCursor.
Header dropping in traefik
Published: 2021-08-05T17:04:21Z
Aliases: CVE-2021-32813

# Impact

There exists a potential header vulnerability in Traefik's handling of the Connection header. Active exploitation of this issue is unlikely, as it requires that a removed header would lead to a privilege escalation, however, the Traefik team has addressed this issue to prevent any potential abuse.

# Details

If you have a chain of Traefik middlewares, and one of them sets a request header `Important-Security-Header`, then sending a request with the following Connection header will cause it to be removed before the request was sent:

```
curl 'https://example.com' -H "Connection: Important-Security-Header" -0
```

In this case, the backend does not see the request header `Important-Security-Header`.

# Patches

Traefik v2.4.x: https://github.com/traefik/traefik/releases/tag/v2.4.13

# Workarounds

No.

# For more information

If you have any questions or comments about this advisory, [open an issue](https://github.com/traefik/traefik/issues).
Data races in appendix
Published: 2021-08-25T20:57:02Z
Aliases: CVE-2020-36469

The `appendix` crate implements a key-value mapping data structure called
`Index<K, V>` that is stored on disk. The crate allows for any type to inhabit
the generic `K` and `V` type parameters and implements Send and Sync for them
unconditionally.

Using a type that is not marked as `Send` or `Sync` with `Index` can allow it
to be used across multiple threads leading to data races. Additionally using
reference types for the keys or values will lead to the segmentation faults
in the crate's code.
Data races in lock_api
Published: 2021-08-25T20:50:00Z
Aliases: CVE-2020-35912

An issue was discovered in the lock_api crate before 0.4.2 for Rust. A data race can occur because of MappedRwLockWriteGuard unsoundness.
Improper random number generation in nanorand
Published: 2021-08-25T20:50:24Z
Aliases: CVE-2020-35926

In versions of nanorand prior to 0.5.1, RandomGen implementations for standard unsigned integers could fail to properly generate numbers, due to using bit-shifting to truncate a 64-bit number, rather than just an as conversion. This often manifested as RNGs returning nothing but 0, including the cryptographically secure ChaCha random number generator.
Improper Restriction of XML External Entity Reference in Quokka
Published: 2021-08-30T16:23:34Z
Aliases: CVE-2020-18703

XML External Entities (XXE) in Quokka v0.4.0 allows remote attackers to execute arbitrary code via the component 'quokka/utils/atom.py'.
Exposed phpinfo() leadked via documentation files
Published: 2021-08-30T16:13:40Z
Aliases: CVE-2021-37704

### Impact
The `phpinfo()` can be exposed if the `/vendor` is not protected from public access. This is a rare situation today since the vendor directory is often located outside the web directory or protected via server rule (.htaccess, etc).

### Patches
Only the v6, v7 and v8 will be patched respectively in 8.0.7, 7.1.2, 6.1.5.
Older versions such as v5, v4 are not longer supported and will **NOT** be patched.

### Workarounds
Protect the `/vendor` directory from public access.

### References
The first issue revealing this vulnerability is located here: https://github.com/flextype/flextype/issues/567
V6 fix: https://github.com/PHPSocialNetwork/phpfastcache/pull/815
V7 fix: https://github.com/PHPSocialNetwork/phpfastcache/pull/814
V8 fix: https://github.com/PHPSocialNetwork/phpfastcache/pull/813

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [our issue tracker](https://github.com/PHPSocialNetwork/phpfastcache/issues)
* Email us at [security@geolim4.com](mailto:security@geolim4.com)
Failure to properly verify ed25519 signatures in libp2p-core
Published: 2021-08-25T20:44:08Z
Aliases: CVE-2019-15545

Affected versions of this crate did not properly verify ed25519 signatures. Any signature with a correct length was considered valid. This allows an attacker to impersonate any node identity.
Data races on syncpool
Published: 2021-08-25T21:00:28Z

Affected versions of this crate unconditionally implements `Send` for `Bucket2`. This allows sending non-Send types to other threads.

This can lead to data races when non Send types like `Cell<T>` or `Rc<T>` are contained inside `Bucket2` and sent across thread boundaries. The data races can potentially lead to memory corruption (as demonstrated in the PoC from the original report issue).

The flaw was corrected in commit `15b2828` by adding a `T: Send` bound to the `Send` impl of `Bucket2<T>`.
Unrestricted Upload of File with Dangerous Type in django-widgy
Published: 2021-08-30T16:24:08Z
Aliases: CVE-2020-18704

Unrestricted Upload of File with Dangerous Type in Django-Widgy v0.8.4 allows remote attackers to execute arbitrary code via the 'image' widget in the component 'Change Widgy Page'.
Improper Handling of Unexpected Data Type in ced
Published: 2021-08-23T19:42:28Z
Aliases: CVE-2021-39131

### Impact

In ced v0.1.0, passing data types other than `Buffer` causes the Node.js process to crash.

### Patches

The problem has been patched in [ced v1.0.0](https://github.com/sonicdoe/ced/releases/tag/v1.0.0). You can upgrade from v0.1.0 without any breaking changes.

### Workarounds

Before passing an argument to ced, verify it’s a `Buffer` using [`Buffer.isBuffer(obj)`](https://nodejs.org/api/buffer.html#buffer_static_method_buffer_isbuffer_obj).

### CVSS score

[CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H/RL:O/RC:C](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H/RL:O/RC:C)

Base Score: 7.5 (High)
Temporal Score: 7.2 (High)

Since ced is a library, the scoring is based on the “[reasonable worst-case implementation scenario](https://www.first.org/cvss/v3.1/user-guide#3-7-Scoring-Vulnerabilities-in-Software-Libraries-and-Similar)”, namely, accepting data from untrusted sources over a network and passing it directly to ced. Depending on your specific implementation, the vulnerability’s severity in your program may be different.

### Proof of concept

```js
const express = require("express");
const bodyParser = require("body-parser");
const ced = require("ced");

const app = express();

app.use(bodyParser.raw());

app.post("/", (req, res) => {
  const encoding = ced(req.body);

  res.end(encoding);
});

app.listen(3000);
```

`curl --request POST --header "Content-Type: text/plain" --data foo http://localhost:3000` crashes the server.

### References

- https://github.com/sonicdoe/ced/commit/a4d9f10b6bf1cd468d1a5b9a283cdf437f8bb7b3
Heap OOB in `RaggedGather`
Published: 2021-08-25T14:43:59Z
Aliases: CVE-2021-37641

### Impact
If the arguments to `tf.raw_ops.RaggedGather` don't determine a valid ragged tensor code can trigger a read from outside of bounds of heap allocated buffers.
                                                                                                                                                                                                                                                                                          
```python
import tensorflow as tf

tf.raw_ops.RaggedGather(
  params_nested_splits = [0,0,0],
  params_dense_values = [1,1],
  indices = [0,0,9,0,0],
  OUTPUT_RAGGED_RANK=0)
```

In debug mode, the same code triggers a `CHECK` failure.

The [implementation](https://github.com/tensorflow/tensorflow/blob/8d72537c6abf5a44103b57b9c2e22c14f5f49698/tensorflow/core/kernels/ragged_gather_op.cc#L70) directly reads the first dimension of a tensor shape before checking that said tensor has rank of at least 1 (i.e., it is not a scalar). Furthermore, the implementation does not check that the list given by `params_nested_splits` is not an empty list of tensors.

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

The fix will be included in TensorFlow 2.6.0. We will also cherrypick this commit on TensorFlow 2.5.1, TensorFlow 2.4.3, and TensorFlow 2.3.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.
Cross site scripting in comrak
Published: 2021-08-25T20:52:12Z
Aliases: CVE-2021-27671

An issue was discovered in the comrak crate before 0.9.1 for Rust. Cross site scripting (XSS) can occur because the protection mechanism for data: and javascript: URIs is case-sensitive, allowing (for example) Data: to be used in an attack.
Excessive memory usage in tokio-rustls
Published: 2021-08-25T20:46:54Z
Aliases: CVE-2020-35875

tokio-rustls does not call process_new_packets immediately after read, so the expected termination condition wants_read always returns true. As long as new incoming data arrives faster than it is processed and the reader does not return pending, data will be buffered. This may cause DoS.
Misinterpretation of malicious XML input
Published: 2021-08-03T16:57:05Z
Aliases: CVE-2021-32796

### Impact
xmldom versions 0.6.0 and older do not correctly escape special characters when serializing elements removed from their ancestor. This may lead to unexpected syntactic changes during XML processing in some downstream applications.

### Patches
Update to one of the fixed versions of `@xmldom/xmldom` (`>=0.7.0`)

See issue #271 for the status of publishing `xmldom` to npm or join #270 for Q&A/discussion until it's resolved.

### Workarounds

Downstream applications can validate the input and reject the maliciously crafted documents.

### References

Similar to this one reported on the Go standard library:

- https://mattermost.com/blog/coordinated-disclosure-go-xml-vulnerabilities/
- https://mattermost.com/blog/securing-xml-implementations-across-the-web/

### For more information

If you have any questions or comments about this advisory:

* Open an issue in [`xmldom/xmldom`](https://github.com/xmldom/xmldom)
* Email us: send an email to **all** addresses that are shown by `npm owner ls @xmldom/xmldom`
Integer overflow in pywin32
Published: 2021-08-09T20:43:44Z
Aliases: CVE-2021-32559

An integer overflow exists in pywin32 prior to version b301 when adding an access control entry (ACE) to an access control list (ACL) that would cause the size to be greater than 65535 bytes. An attacker who successfully exploited this vulnerability could crash the vulnerable process.
XStream is vulnerable to an Arbitrary Code Execution attack
Published: 2021-08-25T14:47:46Z
Aliases: CVE-2021-39147

### Impact
The vulnerability may allow a remote attacker to load and execute arbitrary code from a remote 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
XStream 1.4.18 uses no longer a blacklist by default, since it cannot be secured for general purpose.

### 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-39147](https://x-stream.github.io/CVE-2021-39147.html).

### Credits
wh1t3p1g from TSRC (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)
* Contact us at [XStream Google Group](https://groups.google.com/group/xstream-user)
Data races in lock_api
Published: 2021-08-25T20:50:02Z
Aliases: CVE-2020-35913

An issue was discovered in the lock_api crate before 0.4.2 for Rust. A data race can occur because of RwLockReadGuard unsoundness.
Out of bounds write in slice-deque
Published: 2021-08-25T20:44:10Z
Aliases: CVE-2019-15543

Affected versions of this crate entered a corrupted state if mem::size_of::<T>() % allocation_granularity() != 0 and a specific allocation pattern was used: sufficiently shifting the deque elements over the mirrored page boundary.

This allows an attacker that controls controls both element insertion and removal to corrupt the deque, such that reading elements from it would read bytes corresponding to other elements in the deque. (e.g. a read of T could read some bytes from one value and some bytes from an adjacent one, resulting in a T whose value representation is not meaningful). This is undefined behavior.

The flaw was corrected by using a pair of pointers to track the head and tail of the deque instead of a pair of indices. This pair of pointers are represented using a Rust slice.
Data races in noise_search
Published: 2021-08-25T20:56:05Z
Aliases: CVE-2020-36461

Affected versions of the `noise_search` crate unconditionally implement Send/Sync for `MvccRwLock`.
This can lead to data races when types that are either `!Send` or `!Sync` (e.g. `Rc<T>`, `Arc<Cell<_>>`) are contained inside `MvccRwLock` and sent across thread boundaries. The data races can potentially lead to memory corruption (as demonstrated in the PoC from the original report issue).

Also, safe APIs of `MvccRwLock` allow aliasing violations by allowing `&T` and `LockResult<MutexGuard<Box<T>>>` to co-exist in conflicting lifetime regions. The APIs of `MvccRwLock` should either be marked as `unsafe` or `MbccRwLock` should be changed to private or pub(crate).
Data races in model
Published: 2021-08-25T20:56:07Z
Aliases: CVE-2020-36460

`Shared` data structure in `model` crate implements `Send` and `Sync` traits regardless of the inner type.
This allows safe Rust code to trigger a data race, which is undefined behavior in Rust.

Users are advised to treat `Shared` as an unsafe type.
It should not be used outside of the testing context,
and care must be taken so that the testing code does not have a data race
besides a race condition that is expected to be caught by the test.
Error on unsupported architectures in raw-cpuid
Published: 2021-08-25T20:53:07Z
Aliases: CVE-2021-26307

native_cpuid::cpuid_count() exposes the unsafe __cpuid_count() intrinsic from core::arch::x86 or core::arch::x86_64 as a safe function, and uses it internally, without checking the safety requirement:

* The CPU the program is currently running on supports the function being called.

CPUID is available in most, but not all, x86/x86_64 environments. The crate compiles only on these architectures, so others are unaffected. This issue is mitigated by the fact that affected programs are expected to crash deterministically every time.

The flaw has been fixed in v9.0.0, by intentionally breaking compilation when targeting SGX or 32-bit x86 without SSE. This covers all affected CPUs.
Data races in model
Published: 2021-08-25T20:59:24Z

`Shared` data structure in `model` crate implements `Send` and `Sync` traits regardless of the inner type.
This allows safe Rust code to trigger a data race, which is undefined behavior in Rust.

Users are advised to treat `Shared` as an unsafe type.
It should not be used outside of the testing context,
and care must be taken so that the testing code does not have a data race
besides a race condition that is expected to be caught by the test.

Check [the Rustonomicon](https://doc.rust-lang.org/nomicon/races.html) for the difference between
a data race and a general race condition.
Use-after-free in yottadb
Published: 2021-08-25T20:55:30Z
Aliases: CVE-2021-27377

An issue was discovered in the yottadb crate before 1.2.0 for Rust. For some memory-allocation patterns, ydb_subscript_next_st and ydb_subscript_prev_st have a use-after-free.
nb-connect invalidly assumes the memory layout of std::net::SocketAddr
Published: 2021-08-25T20:52:14Z
Aliases: CVE-2021-27376

The nb-connect crate has assumed std::net::SocketAddrV4 and std::net::SocketAddrV6 have the same memory layout as the system C representation sockaddr. It has simply casted the pointers to convert the socket addresses to the system representation. The standard library does not say anything about the memory layout, and this will cause invalid memory access if the standard library changes the implementation. No warnings or errors will be emitted once the change happens.
XStream is vulnerable to an Arbitrary Code Execution attack
Published: 2021-08-25T14:46:49Z
Aliases: CVE-2021-39153

### Impact
The vulnerability may allow a remote attacker to load and execute arbitrary code from a remote host only by manipulating the processed input stream, if using the version out of the box with Java runtime version 14 to 8 or with JavaFX installed. No user is affected, who followed the recommendation to setup XStream's security framework with a whitelist limited to the minimal required types.

### Patches
XStream 1.4.18 uses no longer a blacklist by default, since it cannot be secured for general purpose.

### 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-39153](https://x-stream.github.io/CVE-2021-39153.html).

### Credits
Ceclin and YXXX from the 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)
* Contact us at [XStream Google Group](https://groups.google.com/group/xstream-user)
Null pointer dereference in `SparseTensorSliceDataset`
Published: 2021-08-25T14:43:32Z
Aliases: CVE-2021-37647

### Impact
When a user does not supply arguments that determine a valid sparse tensor, `tf.raw_ops.SparseTensorSliceDataset` implementation can be made to dereference a null pointer:

```python
import tensorflow as tf

tf.raw_ops.SparseTensorSliceDataset(
  indices=[[],[],[]],
  values=[1,2,3],
  dense_shape=[3,3])
```
  
The [implementation](https://github.com/tensorflow/tensorflow/blob/8d72537c6abf5a44103b57b9c2e22c14f5f49698/tensorflow/core/kernels/data/sparse_tensor_slice_dataset_op.cc#L240-L251) has some argument validation but fails to consider the case when either `indices` or `values` are provided for an empty sparse tensor when the other is not.

If `indices` is empty (as in the example above), then [code that performs validation](https://github.com/tensorflow/tensorflow/blob/8d72537c6abf5a44103b57b9c2e22c14f5f49698/tensorflow/core/kernels/data/sparse_tensor_slice_dataset_op.cc#L260-L261) (i.e., checking that the indices are monotonically increasing) results in a null pointer dereference: 

```cc
    for (int64_t i = 0; i < indices->dim_size(0); ++i) {
      int64_t next_batch_index = indices->matrix<int64>()(i, 0);
      ...
    }
```

If `indices` as provided by the user is empty, then `indices` in the C++ code above is backed by an empty `std::vector`, hence calling `indices->dim_size(0)` results in null pointer dereferencing (same as calling `std::vector::at()` on an empty vector).

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

The fix will be included in TensorFlow 2.6.0. We will also cherrypick this commit on TensorFlow 2.5.1, TensorFlow 2.4.3, and TensorFlow 2.3.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.
Cross-site scripting vulnerability in file upload
Published: 2021-08-30T16:18:59Z
Aliases: CVE-2021-39136

There is a cross-site scripting vulnerability in file upload on the management system of baserCMS.

This is a vulnerability that needs to be addressed when the management system is used by an unspecified number of users.
If you are eligible, please update to the new version as soon as possible.

### Target
baserCMS 4.5.1 and earlier versions

### Vulnerability
Execution of malicious JavaScript code may alter the display of the page or leak cookie information.

### Countermeasures
Update to the latest version of baserCMS

Please refer to the next page for details.
https://basercms.net/security/JVN_14134801
Data races in conquer-once
Published: 2021-08-25T20:50:49Z
Aliases: CVE-2020-36208

Affected versions of conquer-once implements Sync for its OnceCell type without restricting it to Sendable types.

This allows non-Send but Sync types such as MutexGuard to be sent across threads leading to undefined behavior and memory corruption in concurrent programs.

The issue was fixed by adding a Send constraint to OnceCell.
Soundness issue in raw-cpuid
Published: 2021-08-25T20:53:10Z
Aliases: CVE-2021-26306

VendorInfo::as_string(), SoCVendorBrand::as_string(), and ExtendedFunctionInfo::processor_brand_string() construct byte slices using std::slice::from_raw_parts(), with data coming from #[repr(Rust)] structs. This is always undefined behavior.
This flaw has been fixed in v9.0.0, by making the relevant structs #[repr(C)].