readFloat
: memory exhaustion with large exponentNumeric.readFloat
takes time and memory linear in the size of the
number denoted by the input string. In particular, processing a
number expressed in scientific notation with a very large exponent
could cause a denial of service. The slowdown is observable on a
modern machine running GHC 9.4.4:
ghci> import qualified Numeric
ghci> Numeric.readFloat "1e1000000" -- near instantaneous
[(Infinity,"")]
ghci> Numeric.readFloat "1e10000000" -- perceptible pause
[(Infinity,"")]
ghci> Numeric.readFloat "1e100000000" -- ~ 3 seconds
[(Infinity,"")]
ghci> Numeric.readFloat "1e1000000000" -- ~ 35 seconds
[(Infinity,"")]
Numeric.readFloat
is defined for all RealFrac a => a
:
readFloat :: RealFrac a => ReadS a
The RealFrac
type class does not express any bounds on the size of
values representable in the types for which instances exist, so
bounds checking is not possible (in this generic function).
readFloat
uses to Text.Read.Lex.numberToRational
which, among
other things, calculates 10 ^ exponent
, which seems to take linear
time and memory.
Mitigation: use read
. The Read
instances for Float
and
Double
perform bounds checks on the exponent, via
Text.Read.Lex.numberToRangedRational
.
The issue was detected in toml-reader version 0.1.0.0, and
mitigated in version 0.2.0.0 by immediately returning Infinity
when the exponent is large enough that there's no reason to process
it.