Potential DOS in `readFloat` taking time linear in the size of the denoted number
Summary
Numeric.readFloat
seems to take time linear in the size of the denoted number. This means that, when run on untrusted input, an attacker can cause the machine to use a great deal of CPU resources to discover that 1e10000000000000000000000000000
denotes Infinity
.
This may not be fixable, given the type signature, but it would be useful to at least warn about this in the Haddocks.
This problem has surfaced in at least one real library: https://github.com/brandonchinn178/toml-reader/issues/8
Steps to reproduce
Open ghci. Type the following sequence of commands:
$ ghci
GHCi, version 9.4.4: https://www.haskell.org/ghc/ :? for help
ghci> import qualified Numeric
ghci> Numeric.readFloat "1e1000000"
[(Infinity,"")]
ghci> Numeric.readFloat "1e10000000"
[(Infinity,"")]
ghci> Numeric.readFloat "1e100000000"
[(Infinity,"")]
ghci> Numeric.readFloat "1e100000000"
[(Infinity,"")]
ghci> Numeric.readFloat "1e1000000000"
[(Infinity,"")]
ghci> :t Numeric.readFloat "1e1000000000"
Numeric.readFloat "1e1000000000" :: RealFrac a => [(a, String)]
Each takes approximately ten times as long as the prior to run - the last one takes around 35 seconds (timed with a stopwatch) on my machine.
Expected behavior
I would expect either that the Haddocks would warn about this, or that Infinity
would be returned quickly.
Environment
- GHC version used: 9.4.4
Optional:
- Operating System: Fedora 38
- System Architecture: 64-bit Intel