mirror of
https://github.com/nmap/nmap.git
synced 2026-06-25 02:27:59 +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);
|
||
|---|---|---|
| .. | ||
| config | ||
| include | ||
| src | ||
| acconfig.h | ||
| aclocal.m4 | ||
| configure | ||
| configure.in | ||
| dnet-config.in | ||
| INSTALL | ||
| libdnet-stripped.vcxproj | ||
| LICENSE | ||
| Makefile.am | ||
| Makefile.am.common | ||
| Makefile.in | ||
| NMAP_MODIFICATIONS | ||
| README | ||
| THANKS | ||
| TODO | ||
libdnet ------- libdnet provides a simplified, portable interface to several low-level networking routines, including network address manipulation, kernel arp(4) cache and route(4) table lookup and manipulation, network firewalling, network interface lookup and manipulation, IP tunnelling, and raw IP packet and Ethernet frame transmission. WWW: http://libdnet.sourceforge.net/ $Id: README 578 2005-02-14 21:00:17Z dugsong $