[fpc-pascal] Bug 37080 -- StrToHostAddr accepts all Pascal number notations

[Noel Duffy]

On 17/05/20 3:00 am, Michael Van Canneyt wrote:
> 
> 
> On Sat, 16 May 2020, Michael Van Canneyt wrote:
> 
>>
>>
>> On Sat, 16 May 2020, Jonas Maebe wrote:
>>
>>> On 15/05/2020 12:39, Noel Duffy via fpc-pascal wrote:
>>>> While doing some work on bug 37060, the refactoring of StrToHostAddr 
>>>> and
>>>> StrToHostAddr6 in the sockets
>>>> unit,(https://bugs.freepascal.org/view.php?id=37060), I found that
>>>> StrToHostAddr is doing no validation at all on input address characters
>>>> before calling the function Val, so any Pascal notation that Val
>>>> accepts, such as 0x and $ for hexadecimal, % for binary, & for octal,
>>>> and mathematical signs are all accepted in ipv4 octets.
>>>
>>> I added a note to https://bugs.freepascal.org/view.php?id=37013 about
>>> the fact that this test program fails if range checking is enabled (I
>>> don't know if the range error is in StrToHostAddr6 or in the test
>>> program itself).
>>
>> I will check. I never use range checking, so that could have easily 
>> escaped me.
> 
> Fixed 2 occurrences of a range check.

Looking at the code  in SVN, I spotted a couple of still extant 
references to s6_addr16 instead of u6_addr16 in StrToHostAddr6. It's 
possible to trigger range check errors for them. All s6_addr16s should 
be u6_addr16s.

If you try parsing an address like '::ffff' it will hit this part of the 
code.

Sorry for the screw-up. Normally I religiously use range checks in my 
own code, but it completely went out of my head when working on this.