This reflects a deprecation in the official CPE dictionary, which seems
to have happened on 2012-03-08.
<cpe-item deprecation_date="2012-03-08T20:00:15.120Z" deprecated_by="cpe:/o:linux:linux_kernel:2.6.0" deprecated="true" name="cpe:/o:linux:kernel:2.6.0">
<title xml:lang="en-US">Linux Kernel 2.6.0</title>
<meta:item-metadata modification-date="2012-03-08T20:00:15.120Z" status="DRAFT" deprecated-by-nvd-id="35565" nvd-id="91585" />
</cpe-item>
There was an embarrasing bug here added in r28874. In the second of
three calls to get_srcaddr, the interface was being indexed by an index
variable that, in this place, was actually an index into the routes
table. This would in general produce a nonsensical source address or
out-of-bounds access.
The symptom of this problem was the following error messages:
get_srcaddr: can't connect socket: The requested address is not valid in its context.
Failed to convert source address to presentation format!?! Error: Unknown error
The first showed that get_srcaddr failed, and the second was caused by
the bogus source address.
http://seclists.org/nmap-dev/2012/q3/859http://seclists.org/nmap-dev/2012/q4/59
The other protocols that are implemented for IPv4 are not implemented
for IPv6, leading to an assertion failure.
nmap: traceroute.cc:749: virtual unsigned char* UDPProbe::build_packet(const sockaddr_storage*, u32*) const: Assertion `source->ss_family == 2' failed.
This was noticed by Pierre Emeriaud.
http://seclists.org/nmap-dev/2012/q4/36
of them had the type ARPHDR_INFINIBAND; this was the case for
IP-over-InfiniBand interfaces. However, This support is not complete
since IPoIB interfaces use 20 bytes for the hardware address, and
currently we only report and handle 6 bytes.
Nmap IP level scans should work without any problem, please refer to
the '--send-ip' switch and to the following thread:
http://seclists.org/nmap-dev/2012/q3/642
This bug was reported by starlight.2012q3.
of them had the type ARPHDR_IEEE80211; this was the case for wireless
interfaces operating in access point mode. This bug was reported by
Sebastiaan Vileijn.
http://seclists.org/nmap-dev/2012/q3/986
Previously we always took the destination address from the packet
buffer, which failed for IPv6 link-local addresses because the packet
buffer does not contain the scope id.
The script was checking the returned data, but not the status. When
status is false, data is actually an error message. So in case of a
timeout, the script was receiving nil, "TIMEOUT" and interpreting
"TIMEOUT" as a response from the server. It looked like this:
Discovered open port 1434/udp on 127.0.0.1
NSE: rpc-grind: RPC checking function response data is not RPC.
NSE: Target port 1434 is not a RPC port.
This was reported by Christopher Clements.
http://seclists.org/nmap-dev/2012/q3/685
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);
It is possible to send so quickly that we start getting EAGAIN on sends.
In listen mode, this means that some sends can get lost. This patch,
adapted from one by Alex Weber, makes sockets blocking for the duration
of the send. This is not as nice as retrying the send through an event
mechanism, but should at least be correct.
http://seclists.org/nmap-dev/2012/q3/670
Compare a similar patch in r13552, which applied to --exec mode.
Using o.magic_port, which is usually used for our source address, or
otherwise is somewhat randomly generated, doesn't make sense here.
Instead, use the same destination ports that we use for host discovery:
80 for TCP and SCTP, and 40125 for UDP.
http://seclists.org/nmap-dev/2012/q3/663
Vlatko reported that this script was taking an inordinate amount of time
even in typical scans. This patch reduces the number of domains tried by
default. The new http-vhosts.filelist script argument allows
substituting the original list or another of your choosing.
Patch by Vlatko.
http://seclists.org/nmap-dev/2012/q3/432
According to rtnetlink(7), such routes are "an unreachable destination."
I get such a route when I ifdown my he-ipv6 interface:
$ /sbin/route -n -A inet6
Kernel IPv6 routing table
Destination Next Hop Flag Met Ref Use If
::/0 :: !n -1 1 26122 lo
The problem with not ignoring such routes is that Nmap will think that
the interface to use is lo, and consequently that all the targets are
localhost addresses. Ping scan will succeed with a localhost-response,
but trying to send any packets will fail with "destination unreachable."
Maybe we should do the same thing for these additional values of
rtm_type?
RTN_BLACKHOLE a packet dropping route
RTN_PROHIBIT a packet rejection route
