An issue was discovered in the libp2p-deflate crate before 0.27.1 for Rust. An uninitialized buffer is passed to AsyncRead::pollread(), which is a user-provided trait function.

libp2p is a JavaScript implementation of the libp2p networking stack. Prior to version 4.2.9, the reservation refresh path in reservation-store.ts reuses the same retimeableSignal but unconditionally registers another abort listener on every refresh. As a result, a remote peer can repeatedly send valid RESERVE requests for the same reservation, causing unbounded listener and closure growth in @libp2p/circuit-relay-v2 relay servers and leading to denial of service. This issue is fixed in version 4.2.9.

An issue was discovered in the libp2p-core crate before 0.8.1 for Rust. Attackers can spoof ed25519 signatures.

Impact A malicious peer can use large RSA keys to run a resource exhaustion attack & force a node to spend time doing signature verification of the large key. This vulnerability is present in the core/crypto module of go-libp2p and can occur during the Noise handshake and the libp2p x509 extension verification step. To prevent this attack, go-libp2p now restricts RSA keys to <= 8192 bits.

Patches Users should upgrade their go-libp2p versions to >=v0.27.8, >= v0.28.2, or >=v0.29.1 To protect your application, it's necessary to update to these patch releases AND to use the updated Go compiler (1.20.7 or 1.19.12, respectively)

Workarounds There are no known workarounds

References The Golang crypto/tls package also had this vulnerability ("verifying certificate chains containing large RSA keys is slow” https://github.com/golang/go/issues/61460) Fix in golang/go crypto/tls: https://github.com/golang/go/commit/2350afd2e8ab054390e284c95d5b089c142db017 Fix in quic-go https://github.com/quic-go/quic-go/pull/4012