| パッケージ | 影響を受けるバージョン | 修正済みバージョン |
|---|---|---|
| co.fs2:fs2-io_0.26 | 全バージョン | |
| co.fs2:fs2-io_0.27 | 全バージョン | |
| co.fs2:fs2-io_2.11 | 全バージョン | |
| co.fs2:fs2-io_2.12 | ≥ 3.0.0-M1, < 3.12.2≥ 3.13.0-M1, < 3.13.0-M7< 2.5.13 | 3.12.23.13.0-M72.5.13 |
| co.fs2:fs2-io_2.12.0-M4 | 全バージョン | |
| co.fs2:fs2-io_2.12.0-M5 | 全バージョン | |
| co.fs2:fs2-io_2.12.0-RC1 | 全バージョン | |
| co.fs2:fs2-io_2.12.0-RC2 | 全バージョン | |
| co.fs2:fs2-io_2.13 |
When establishing a TLS session using fs2-io on the JVM using the fs2.io.net.tls package, if one side of the connection shuts down write while the peer side is awaiting more data to progress the TLS handshake, the peer side will spin loop on the socket read, fully utilizing a CPU. This CPU is consumed until the overall connection is closed.
This could be used as a denial of service attack on an fs2-io powered server -- for example, by opening many connections and putting them in a half-shutdown state.
Note: this issue impacts ember backed http4s servers with HTTPS as a result of ember using fs2's TLS support.
Fixed in fs2 3.12.2 and 3.13.0-M7.
No workarounds.
If you have any questions or comments about this advisory:
Open an issue. Contact the Typelevel Security Team.
これらの製品をお使いですか？サイトをスキャンして、脆弱なバージョンが公開されていないか確認しましょう。
無料でサイトをスキャン≥ 3.0.0-M1, < 3.12.2≥ 3.13.0-M1, < 3.13.0-M7< 2.5.13 |
3.12.23.13.0-M72.5.13 |
| co.fs2:fs2-io_2.13.0-M5 | 全バージョン |
| co.fs2:fs2-io_3 | ≥ 3.0.0-M1, < 3.12.2≥ 3.13.0-M1, < 3.13.0-M7< 2.5.13 | 3.12.23.13.0-M72.5.13 |