Open Bug 1370531 Opened 7 years ago Updated 2 years ago

parseFloat allocates space for entire length of its input string

Categories

(Core :: JavaScript Engine, enhancement, P3)

55 Branch
enhancement

Tracking

()

People

(Reporter: jonco, Unassigned)

References

Details

(Keywords: triage-deferred)

This was pointed out in bug 1349850 where it was used as part of a security exploit to reliably trigger GC based on malloc triggers (the actual vulnerability has been fixed). 

This is pretty wasteful for large strings (e.g. the 1MiB strings in the referenced bug).  Bug 551229 contains some suggestions for addressing this although I'm sure there are other approaches.
See Also: → 551229
I just want to echo Brendan's sentiment in bug 551229 in that there are some tricky problems here and that simply discarding some digits of the input can lead to incorrect rounding in boundary cases.  A good place to start is Clinger's 1990 PLDI paper; I know there are newer papers too, but that one goes through the mechanics thoroughly and discusses various pitfalls.

Are large input strings really a problem in practice?  (I mean, apart from the security / OOM angle, which of course is not uninteresting.)  The floating point formatting routines should generally produce short (optimal or near-optimal) outputs, so unless somebody goes out of their way to produce very large inputs, this would seem to be a corner case.
Keywords: triage-deferred
Priority: -- → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.