Change Details

Portable programs that use SIOCGIFCONF (traceroute) assume that each pseudo ifreq is of length sizeof(ifr_name) + ifr_addr.sa_len. For short sockaddrs we violated this assumption and wrote sizeof(ifr_name) + sizeof(struct sockaddr). We also failed to zero extra sa_data values (not a leak, but could contain contents of previous sockaddrs). I believe only one such sockaddr exists (struct sockaddr_sco which is 8 bytes) and it is unclear if such sockaddrs end up on interfaces in practice. If it did the result would be an 8 byte heap leak.

Portable programs that use SIOCGIFCONF (e.g. traceroute) assume that each pseudo ifreq is of length MAX(sizeof(struct ifreq), sizeof(ifr_name) + ifr_addr.sa_len). For short sockaddrs we copied too much from the source sockaddr resulting in a heap leak. I believe only one such sockaddr exists (struct sockaddr_sco which is 8 bytes) and it is unclear if such sockaddrs end up on interfaces in practice. If it did, the result would be an 8 byte heap leak on current architectures.

Portable programs that use SIOCGIFCONF (e.g. traceroute) assume that each pseudo ifreq is of length MAX(sizeof(struct ifreq), sizeof(ifr_name) + ifr_addr.sa_len). For short sshort sockaddrs we violatcopied this assumption and wrote sizeof(ifr_name) +oo much from the source sockaddr resulting in a heap sizeof(struct sockaddr). We also failed to zero extra sa_data values (not a leak, but could contain contents of previous sockaddrs)leak. I believe only one such sockaddr exists (struct sockaddr_sco which is 8 bytes) and it is unclear if such sockaddrs end up on interfaces in practice. If it did, the result would be an 8 byte heap leak on current architectures.