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

[Michael Van Canneyt]

On Sun, 17 May 2020, Noel Duffy via fpc-pascal wrote:

> 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.

That's what you get when communication with someone who doesn't use them:
It's contagious ;-)

I'll have a look.

Michael.