Is this an incorrect Qualcomm usage or a glibc bug?

[Florian Weimer]

On 09/01/2017 12:07 PM, honan li wrote:
> define SASTORAGE_DATA(addr)    (addr).__ss_padding
> 
> typedef struct qcmap_cm_nl_prefix_info_s {
>   boolean prefix_info_valid;
>   unsigned char prefix_len;
>   unsigned int mtu;
>   struct sockaddr_storage prefix_addr;
>   struct ifa_cacheinfo          cache_info;
> } qcmap_cm_nl_prefix_info_t;
> 
> void QCMAP_Backhaul::GetIPV6PrefixInfo(char *devname,
>                                        qcmap_cm_nl_prefix_info_t
> *ipv6_prefix_info)
> {
>   struct sockaddr_in6 *sin6 = NULL;
> 
>   ...
> 
>   sin6 = (struct sockaddr_in6 *)&ipv6_prefix_info->prefix_addr;
>   memcpy(SASTORAGE_DATA(ipv6_prefix_info->prefix_addr),
>          RTA_DATA(rta),
>          sizeof(sin6->sin6_addr));
>   ...
> }

Currently publicly available here:


https://github.com/Bigcountry907/HTC_a13_vzw_Kernel/blob/master/vendor/qcom/proprietary/data/mobileap_v2/server/src/QCMAP_ConnectionManager.cpp#L3658

I would expect applications do something like this instead:

  struct sockaddr_in6 sin6;
  memset (&sin6, 0, sizeof (sin6));
  sin6.sin6_family = AF_INET6;
  memcpy (&sin6.sin6_addr, RTA_DATA (rta), sizeof (sin6.sin6_addr));
  memcpy (&ipv6_prefix_info->prefix_addr, &sin6, sizeof (sin6));

This avoids any aliasing issues and a dependency on the internals of
struct sockaddr_storage (which is only intended as a way to allocate a
generic struct sockaddr of sufficient size and alignment).  It also
initializes the other components of the socket address (such as the port
number and flow label).

Thanks,
Florian