| Package | Affected versions | Patched versions |
|---|---|---|
| co.fs2:fs2-io_0.26 | all versions | |
| co.fs2:fs2-io_0.27 | all versions | |
| co.fs2:fs2-io_2.11 | all versions | |
| 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 | all versions | |
| co.fs2:fs2-io_2.12.0-M5 | all versions | |
| co.fs2:fs2-io_2.12.0-RC1 | all versions | |
| co.fs2:fs2-io_2.12.0-RC2 |
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.
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site freeall versions| co.fs2:fs2-io_2.13 | ≥ 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 | all versions |
| 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 |