mahdibaghbani / hayadi_rs Goto Github PK

Details
Package	h2
Version	0.3.22
URL	n/a
Patched Versions	^0.3.26 OR >=0.4.4
Aliases	GHSA-q6cp-qfwq-4gcv

An attacker can send a flood of CONTINUATION frames, causing h2 to process them indefinitely.
This results in an increase in CPU usage.

Tokio task budget helps prevent this from a complete denial-of-service, as the server can still
respond to legitimate requests, albeit with increased latency.

More details at "https://seanmonstar.com/blog/hyper-http2-continuation-flood/.

Patches available for 0.4.x and 0.3.x versions.

Details
Package	rustls
Version	0.21.10
URL	GHSA-6g7w-8wpp-frhj
Patched Versions	>=0.23.5 OR >=0.22.4, <0.23.0 OR >=0.21.11, <0.22.0
Aliases	CVE-2024-32650, GHSA-6g7w-8wpp-frhj

If a close_notify alert is received during a handshake, complete_io
does not terminate.

Callers which do not call complete_io are not affected.

rustls-tokio and rustls-ffi do not call complete_io
and are not affected.

rustls::Stream and rustls::StreamOwned types use
complete_io and are affected.

Details
Package	mio
Version	0.8.10
URL	GHSA-r8w9-5wcg-vfj7
Patched Versions	>=0.8.11
Unaffected Versions	<0.7.2
Aliases	CVE-2024-27308, GHSA-r8w9-5wcg-vfj7

Impact

When using named pipes on Windows, mio will under some circumstances return invalid tokens that correspond to named pipes that have already been deregistered from the mio registry. The impact of this vulnerability depends on how mio is used. For some applications, invalid tokens may be ignored or cause a warning or a crash. On the other hand, for applications that store pointers in the tokens, this vulnerability may result in a use-after-free.

For users of Tokio, this vulnerability is serious and can result in a use-after-free in Tokio.

The vulnerability is Windows-specific, and can only happen if you are using named pipes. Other IO resources are not affected.

Affected versions

This vulnerability has been fixed in mio v0.8.11.

All versions of mio between v0.7.2 and v0.8.10 are vulnerable.

Tokio is vulnerable when you are using a vulnerable version of mio AND you are using at least Tokio v1.30.0. Versions of Tokio prior to v1.30.0 will ignore invalid tokens, so they are not vulnerable.

Workarounds

Vulnerable libraries that use mio can work around this issue by detecting and ignoring invalid tokens.

Technical details

When an IO resource registered with mio has a readiness event, mio delivers that readiness event to the user using a user-specified token. Mio guarantees that when an IO resource is deregistered, then it will never return the token for that IO resource again. However, for named pipes on windows, mio may sometimes deliver the token for a named pipe even though the named pipe has been previously deregistered.

This vulnerability was originally reported in the Tokio issue tracker: tokio-rs/tokio#6369
This vulnerability was fixed in: tokio-rs/mio#1760

Thank you to @rofoun and @radekvit for discovering and reporting this issue.

Details
Package	whoami
Version	1.4.1
URL	ardaku/whoami#91
Patched Versions	>=1.5.0
Unaffected Versions	<0.5.3
Aliases	GHSA-w5w5-8vfh-xcjq

With versions of the whoami crate >= 0.5.3 and < 1.5.0, calling any of these functions leads to an
immediate stack buffer overflow on illumos and Solaris:

• whoami::username
• whoami::realname
• whoami::username_os
• whoami::realname_os

With versions of the whoami crate >= 0.5.3 and < 1.0.1, calling any of the above functions also
leads to a stack buffer overflow on these platforms:

• Bitrig
• DragonFlyBSD
• FreeBSD
• NetBSD
• OpenBSD

This occurs because of an incorrect definition of the passwd struct on those platforms.

As a result of this issue, denial of service and data corruption have both been observed in the
wild. The issue is possibly exploitable as well.

This vulnerability also affects other Unix platforms that aren't Linux or macOS.

This issue has been addressed in whoami 1.5.0.

For more information, see this GitHub issue.

Details
Package	h2
Version	0.3.22
URL	n/a
Patched Versions	^0.3.24 OR >=0.4.2
Aliases	GHSA-8r5v-vm4m-4g25
Related Advisories	CVE-2019-9514

An attacker with an HTTP/2 connection to an affected endpoint can send a steady stream of invalid frames to force the
generation of reset frames on the victim endpoint.
By closing their recv window, the attacker could then force these resets to be queued in an unbounded fashion,
resulting in Out Of Memory (OOM) and high CPU usage.

This fix is corrected in hyperium/h2#737, which limits the total number of
internal error resets emitted by default before the connection is closed.