This project contains known security vulnerabilities. Find detailed information at the bottom.
libp2p-quic(14 total, 6 outdated, 2 insecure)
| Crate | Required | Latest | Status |
|---|---|---|---|
| async-std | ^1.12.0 | 1.13.2 | up to date |
| bytes | ^1.2.1 | 1.12.1 | up to date |
| futures | ^0.3.15 | 0.3.34 | up to date |
| futures-timer | ^3.0.2 | 3.0.4 | up to date |
| if-watch | ^3.0.0 | 3.2.2 | up to date |
| libp2p-core | ^0.38.0 | 0.44.0 | out of date |
| libp2p-tls | ^0.1.0-alpha | 0.7.0 | out of date |
| log | ^0.4 | 0.4.34 | up to date |
| parking_lot | ^0.12.0 | 0.12.5 | up to date |
| quinn-proto ⚠️ | ^0.9.0 | 0.11.18 | insecure |
| rand | ^0.8.5 | 0.10.3 | out of date |
| rustls ⚠️ | ^0.20.2 | 0.23.45 | insecure |
| thiserror | ^1.0.26 | 2.0.20 | out of date |
| tokio | ^1.21.1 | 1.53.1 | up to date |
(4 total, 1 outdated)
| Crate | Required | Latest | Status |
|---|---|---|---|
| async-std | ^1.12.0 | 1.13.2 | up to date |
| env_logger | ^0.9.0 | 0.11.11 | out of date |
| quickcheck | ^1 | 1.1.0 | up to date |
| tokio | ^1.21.1 | 1.53.1 | up to date |
rustls: `rustls::ConnectionCommon::complete_io` could fall into an infinite loop based on network inputIf 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.
quinn-proto: Denial of service in Quinn endpointsReceiving QUIC transport parameters containing invalid values could lead to a panic.
Unfortunately the maintainers did not properly assess usage of unwrap() calls in the
transport parameters parsing code, and we did not have sufficient fuzzing coverage to find this
issue. We have since added a fuzzing target to cover this code path.
quinn-proto: Remote memory exhaustion in quinn-proto from unbounded out-of-order stream reassemblyThe Assembler component that assembles unordered stream fragments into consecutive chunks of the
stream incurs some overhead for non-contiguous fragments. Readers that read from a RecvStream in
order (through an AsyncRead impl for example) will be sensitive to peers that send fragments
while leaving out early parts of the stream, and in particular, fragments with many gaps (because
these cannot be defragmented). In such a scenario, the receiving connection suffers from high
buffer overhead, enabling memory exhaustion.