mirror of
https://github.com/nmap/nmap.git
synced 2026-01-13 01:49:01 +00:00
0674925f73
On platforms supporting sa_len, NEXTIFR would skip over sa_len bytes
starting at the beginning of ifr_addr, and assume that was the end of
the struct. (The idea being that a large address such as a sockaddr_in6
could overflow the nominal struct boundary.) This logic was wrong when
there was something else in the union bigger than sa_len; we would
increment into somewhere in the middle of the same struct.
This exhibited itself on NetBSD, where struct ifreq has a
sockaddr_storage member in its internal union:
struct ifreq {
char ifr_name[IFNAMSIZ]; /* if name, e.g. "en0" */
union {
struct sockaddr ifru_addr;
struct sockaddr ifru_dstaddr;
struct sockaddr ifru_broadaddr;
struct sockaddr_storage ifru_space;
No, we skip over sa_len bytes, or to the nominal end of the struct,
whichever is larger.
Unix Network Programming gets this wrong too; in figure 17.8 they do
ptr += sizeof(ifr->ifr_name) + max(sizeof(struct sockaddr), ifr->ifr_addr.sa_len);