[classlib][portlib] Bug in IPv6 native code?

[Mark Hindess <ma...@googlemail.com>]

In modules/portlib/src/main/native/port/unix/hysock.c on line 4821, I see:

  interfaces[currentAdapterIndex].
    addresses[currentIPAddressIndex].scope =
    &(((struct sockaddr_in6 *) (&ifc.ifc_req[counter].
                                ifr_addr))->
      sin6_scope_id);

but interfaces[currentAdapterIndex].addresses[currentIPAddressIndex].scope
is a U_32 as defined in modules/portlib/src/main/native/include/unix/hysock.h
on line 260.

So we are assigning an address to a U_32 which definitely isn't a good idea
on 64-bit platforms.  Even on 32-bit platforms I can't understand why we'd
want to do this.  The other assignment to the same field on line 4296 of
hysock.c looks like:

  interfaces[counter].
    addresses[currentIPAddressIndex].
    scope =
    returnedAddrHeader->ifa_index;

which seems a little more reasonable as ifa_index is also a U_32.

These definitely seem inconsistent but it is not immediately obvious to
me what the correct fix is.  Anyone any ideas?

Regards,
 Mark.

Re: [classlib][portlib] Bug in IPv6 native code?

[Tim Ellison <t....@gmail.com>]

Mark Hindess wrote:
> In modules/portlib/src/main/native/port/unix/hysock.c on line 4821, I see:
> 
>   interfaces[currentAdapterIndex].
>     addresses[currentIPAddressIndex].scope =
>     &(((struct sockaddr_in6 *) (&ifc.ifc_req[counter].
>                                 ifr_addr))->
>       sin6_scope_id);
> 
> but interfaces[currentAdapterIndex].addresses[currentIPAddressIndex].scope
> is a U_32 as defined in modules/portlib/src/main/native/include/unix/hysock.h
> on line 260.
> 
> So we are assigning an address to a U_32 which definitely isn't a good idea
> on 64-bit platforms.  Even on 32-bit platforms I can't understand why we'd
> want to do this.  The other assignment to the same field on line 4296 of
> hysock.c looks like:
> 
>   interfaces[counter].
>     addresses[currentIPAddressIndex].
>     scope =
>     returnedAddrHeader->ifa_index;
> 
> which seems a little more reasonable as ifa_index is also a U_32.
> 
> These definitely seem inconsistent but it is not immediately obvious to
> me what the correct fix is.  Anyone any ideas?

That function is a bit of a nightmare, but looking at the definition of
hyipAddress_struct I would imagine that the 32-bit sin6_scope_id *value*
should be copied not the address of the field.

Reading the code I'd be inclined to consider removing the spurious &
(though I'd have to run it through the debugger to see if that was right).

Regards,
Tim