[issue32997] Catastrophic backtracking in fpformat

Benjamin Peterson added the comment: New changeset 55d5bfba9482d39080f7b9ec3e6257ecd23f264f by Benjamin Peterson (Jamie Davis) in branch '2.7': [2.7] closes bpo-32997: Fix REDOS in fpformat (GH-5984) https://github.com/python/cpython/commit/55d5bfba9482d39080f7b9ec3e6257ecd23f264f --

[issue32997] Catastrophic backtracking in fpformat

James Davis added the comment: Equivalent, probably cleaner. Comment on the PR if you want a change. -- ___ Python tracker ___ ___ P

[issue32997] Catastrophic backtracking in fpformat

Serhiy Storchaka added the comment: Wouldn't be easier to remove '0*' from the pattern? 0s could be stripped later by .lstrip('0'). -- nosy: +serhiy.storchaka ___ Python tracker _

[issue32997] Catastrophic backtracking in fpformat

Change by James Davis : -- keywords: +patch pull_requests: +5750 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-list

[issue32997] Catastrophic backtracking in fpformat

New submission from James Davis : The decoder regex used to parse numbers in the fpformat module is vulnerable to catastrophic backtracking. '^([-+]?)0*(\d*)((?:\.\d*)?)(([eE][-+]?\d+)?)$' The substructure '0*(\d*)' is quadratic. An attack string like '+0000++' blows up. There is a risk o