#1265 integer overflow in sscanf-based parsing (glibc)

[Will Dietz]

Problem:

curl's use of sscanf for parsing range glob patterns invokes undefined behavior when the numeric value being parsed is too large to fit into an integer, which on libc silently overflows causing unexpected behavior when using ranges containing large integers.

Examples:

$ curl "http://1/[4294967296-1]"

[1/2]: http://1/0 --> <stdout>
--_curl_--http://1/0
curl: (7) Failed to connect to 0.0.0.1: Invalid argument

[2/2]: http://1/1 --> <stdout>
--_curl_--http://1/1
curl: (7) Failed to connect to 0.0.0.1: Invalid argument

$ curl "http://1/[4294967296-4294967300]"      

[1/5]: http://1/0 --> <stdout>
--_curl_--http://1/0
curl: (7) Failed to connect to 0.0.0.1: Invalid argument

[2/5]: http://1/1 --> <stdout>
--_curl_--http://1/1
curl: (7) Failed to connect to 0.0.0.1: Invalid argument

[3/5]: http://1/2 --> <stdout>
--_curl_--http://1/2
curl: (7) Failed to connect to 0.0.0.1: Invalid argument

[4/5]: http://1/3 --> <stdout>
--_curl_--http://1/3
curl: (7) Failed to connect to 0.0.0.1: Invalid argument

[5/5]: http://1/4 --> <stdout>
--_curl_--http://1/4
curl: (7) Failed to connect to 0.0.0.1: Invalid argument

This also impacts the parsing of the 'step' portion of the range glob.

[Daniel Stenberg]

Confirmed. I have a fix pending.

[Daniel Stenberg]

Fixed in git, commit 5ca96cb84410