ghsa

### Impact An issue was discovered in net/netfilter/nf_tables_api.c in the Linux kernel. A denial of service can occur upon binding to an already bound chain. Affected by this vulnerability is the function nft_verdict_init of the file net/netfilter/nf_tables_api.c. The manipulation with an unknown input leads to a denial of service vulnerability. The program does not release or incorrectly releases a resource before it is made available for re-use. ### Patches The fix has been backported to [5.15.64](https://www.linuxkernelcves.com/cves/CVE-2022-39190) version of the upstream Linux kernel (5.15 is the upstream Kernel long term version Talos ships with). Talos >= v1.2.0 is shipped with Linux Kernel 5.15.64 fixing the above issue. ### Workarounds It's recommended to upgrade ### References - https://www.sesin.at/2022/09/02/cve-2022-39190-linux-kernel-up-to-5-19-5-nf_tables_api-c-nft_verdict_init-denial-of-service/ - https://nvd.nist.gov/vuln/detail/CVE-2022-39190 ### For more informa...

### Impact A race condition was found in the Linux kernel's IP framework for transforming packets (XFRM subsystem) when multiple calls to xfrm_probe_algs occurred simultaneously. This flaw could allow a local attacker to potentially trigger an out-of-bounds write or leak kernel heap memory by performing an out-of-bounds read and copying it into a socket. ### Patches The fix has been backported to [5.15.64](https://www.linuxkernelcves.com/cves/CVE-2022-3028) version of the upstream Linux kernel (5.15 is the upstream Kernel long term version Talos ships with). Talos >= v1.2.0 is shipped with Linux Kernel 5.15.64 fixing the above issue. Kubernetes workloads running in Talos are not affected since user namespaces are disabled in Talos kernel config. So an unprivileged user cannot obtain CAP_NET_ADMIN by unsharing. However untrusted workloads that run with privileged: true or having NET_ADMIN capability poses a risk. ### Workarounds Audit kubernetes workloads running in the cluster with ...

### Issue If an attacker is able to control a threshold of keys to insert the same public key more than once with different key IDs into signed, trusted metadata on a TUF repository, then go-tuf [clients](https://github.com/theupdateframework/go-tuf#client) < [0.3.2](https://github.com/theupdateframework/go-tuf/releases/tag/v0.3.2) are susceptible to an attack where attackers can cause the same signature from the same public key to be counted more than once against the threshold of signatures because they were mistakenly distinguished due to having different key IDs. For example, suppose that in the root metadata file, there were a threshold of 2 self-signatures required from 2 different keys $K_A$ and $K_B$ belonging to Alice and Bob respectively. Bob has either mistakenly or maliciously produced a signed a malicious version of the root metadata file where Alice's key is listed once with the keyid $SHA2_{256}(K_A)$, but his public key is listed twice, once with the keyid $SHA2_{256}...

> ### Meta > * CVSS: `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H/E:F/RL:O/RC:C` (5.5) ### Problem Requesting invalid or non-existing resources via HTTP triggers the page error handler which again could retrieve content to be shown as an error message from another page. This leads to a scenario in which the application is calling itself recursively - amplifying the impact of the initial attack until the limits of the web server are exceeded. This vulnerability is the same as described in [TYPO3-CORE-SA-2021-005](https://typo3.org/security/advisory/typo3-core-sa-2021-005) ([CVE-2021-21359](https://nvd.nist.gov/vuln/detail/CVE-2021-21359)). A regression, introduced during TYPO3 v11 development, led to this situation. ### Solution Update to TYPO3 version 11.5.16 that fixes the problem described above. ### Credits Thanks to Rik Willems who reported this issue and to TYPO3 core & security team member Oliver Hader who fixed the issue. ### References * [TYPO3-CORE-SA-2022-006](https://...

> ### Meta > * CVSS: `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N/E:F/RL:O/RC:C` (4.9) ### Problem It has been discovered that observing response time during user authentication (backend and frontend) can be used to distinguish between existing and non-existing user accounts. Extension authors of 3rd party TYPO3 extensions providing a custom authentication service should check if the extension is affected by the described problem. Affected extensions must implement new `MimicServiceInterface::mimicAuthUser`, which simulates corresponding times regular processing would usually take. ### Solution Update to TYPO3 version 7.6.58 ELTS, 8.7.48 ELTS, 9.5.37 ELTS, 10.4.32 or 11.5.16 that fix the problem described above. ### Credits Thanks to Vautia who reported this issue and to TYPO3 core & security team members Oliver Hader who fixed the issue. ### References * [TYPO3-CORE-SA-2022-007](https://typo3.org/security/advisory/typo3-core-sa-2022-007) * [Vulnerability Report on huntr.dev](htt...

> ### Meta > * CVSS: `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N/E:F/RL:O/RC:C` (5.0) ### Problem It has been discovered that the expiration time of a password reset link for TYPO3 backend users has never been evaluated. As a result, a password reset link could be used to perform a password reset even if the default expiry time of two hours has been exceeded. ### Solution Update to TYPO3 version 10.4.32 or 11.5.16 that fix the problem described above. ### Credits Thanks to Ingo Fabbri who reported this issue and to TYPO3 security team member Torben Hansen who fixed the issue. ### References * [TYPO3-CORE-SA-2022-008](https://typo3.org/security/advisory/typo3-core-sa-2022-008)

> ### Meta > * CVSS: `CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N/E:F/RL:O/RC:C` (5.0) ### Problem It has been discovered that the `FileDumpController` (backend and frontend context) is vulnerable to cross-site scripting when malicious files are displayed using this component. A valid backend user account is needed to exploit this vulnerability. ### Solution Update to TYPO3 version 7.6.58 ELTS, 8.7.48 ELTS, 9.5.37 ELTS, 10.4.32 or 11.5.16 that fix the problem described above. ### Credits Thanks to Vautia who reported this issue and to TYPO3 core & security team member Oliver Hader who fixed the issue. ### References * [TYPO3-CORE-SA-2022-009](https://typo3.org/security/advisory/typo3-core-sa-2022-009) * [Vulnerability Report on huntr.dev](https://huntr.dev/bounties/51e9b709-193c-41fd-bd4a-833aaca0bd4e/) (embargoed +30 days)

> ### Meta > * CVSS: `CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:L/I:L/A:N/E:F/RL:O/RC:C` (4.1) ### Problem It has been discovered that the `f:asset.css` view helper is vulnerable to cross-site scripting when user input is passed as variables to the CSS. ### Solution Update to TYPO3 version 10.4.32 or 11.5.16 that fix the problem described above. ### Credits Thanks to TYPO3 contributor member Frank Nägler who reported this issue and to TYPO3 core & security team member Oliver Hader who fixed the issue. ### References * [TYPO3-CORE-SA-2022-010](https://typo3.org/security/advisory/typo3-core-sa-2022-010)

The maintainer seems unreachable. The crate may or may not be usable as-is despite no maintenance and may not work in future versions of Rust. The last release seems to have been seven years ago.

Crate `traitobject` has not had a release for over five years. In addition there is an existing security advisory that has not been addressed: - [RUSTSEC-2020-0027](https://rustsec.org/advisories/RUSTSEC-2020-0027) ## Possible Alternative(s) The below list has not been vetted in any way and may or may not contain alternatives; - [destructure_traitobject] [destructure_traitobject]: https://crates.io/crates/destructure_traitobject