----------------------------
revision 1.95
date: 2019-05-28 05:56:46 +0200; author: kamil; state: Exp; lines: +2 -2; commitid: YrUzDYl5zfcjiVoB;
Decorate struct in6_addr with the __packed attribute
This avoids undefined behavior when accessing misaligned pointers.
Detected by kUBSan.
Patch by Akul Pillai.
----------------------------
This change caused regression in at least qemu and addresses potential binary ABI breakage.
Fixes PR/54523 by <gson>
Once we've sent nd6_mmaxtries NS messages, send RTM_MISS and move to the
ND6_LLINFO_WAITDELETE state rather than freeing the llentry right away.
Wait for a probe cycle and then free the llentry.
If a connection attempts to re-use the llentry during ND6_LLINFO_WAITDELETE,
return EHOSTDOWN (or EHOSTUNREACH if a gateway) to match inet behaviour.
Continue to ND6_LLINFO_INCOMPLETE and send another NS probe in hope of a
reply. Rinse and repeat.
This reverts part of nd6.c r1.14 - an 18 year old commit!
Takes the same approach as when adding a new address - we no longer
announce the new lladdr right away but we announce the result.
This will either be RTM_ADD or RTM_MISS.
RTM_DELETE is only sent if we have a lladdr assigned OR gc'ed.
This results in less messages via route(4) and tells us when a new
lladdr has been added (RTM_ADD), changed (RTM_CHANGE), deleted (RTM_DELETED)
or has failed to been resolved (RTM_MISS). The latter case can be
interpreted as unreachable.
However, RFC 4861 6.2.5 only says departing routers
*SHOULD* send RA with lifetime of zero and *MUST*
send all subsequent NA messages if the router flag
unset.
To help userland avoid the expensive process of
parsing NA messages, send RTM_CHANGE without a
lladdr in the gateway.
This is different from the intial RTM_ADD also
without a lladdr in the gateway and RTM_DELETE.
This hasn't been the case for a long time if you're a dhcpcd
user with a default config. As such, it's possible for the default
IPv6 router as set by dhcpcd could be erroneously gc'ed by nd6_free.
This reduces the scope of the ND6_WLOCK taken as well as fixing an
issue where we write to ln->ln_state without a lock being held.
On sending a packet over a STALE cache, the cache should be tried a reachability
confirmation, which is described in RFC 2461/4861 7.3.3. On the fast path in
nd6_resolve, however, the treatment for STALE caches has been skipped
accidentally. So STALE caches never be back to the REACHABLE state.
To fix the issue, branch to the fast path only when the cache entry is the
REACHABLE state and leave other caches to the slow path that includes the
treatment. To this end we need to allow to return a link-layer address if a
valid address is available on the slow path too, which is the same behavior as
FreeBSD and OpenBSD.
The IFNET_LOCK was added to avoid data races on if_flags for IFF_ALLMULTI.
Unfortunatetly it caused a deadlock instead. A known scenario causing a
deadlock is to occur the following two operations concurrently: (a) a removal of
an IP adddres assigned to an interface and (b) a manipulation of multicast
groups to the interface. The resource dependency graph is like this:
softnet_lock => IFNET_LOCK => psref_target_destroy => softint => softnet_lock
Thanks to the previous commit that avoids data races on if_flags for
IFF_ALLMULTI by another approach, we can remove IFNET_LOCK and defuse the
deadlock.
PR kern/54189
Use this when we notify userland of a duplicate address
and set RTA_AUTHOR to the hardware address of the sender.
While here, match the logging diagnostic of INET6 to the simpler one
of INET so it's consistent.
in6_pcballoc, otherwise if it fails there is still a PCB attached, and
we hit a KASSERT in socreate. In !DIAGNOSTIC this would have caused a
memory leak.
By the way I find the splsoftnet highly suspicious, in6_pcballoc already
does that.
Triggered by SyzKaller.
Reported-by: syzbot+7bace612ca3cc3e124f8@syzkaller.appspotmail.com
Unless it's lo0, where we then flush the lot.
The maintains the status-quo with ndp(8) and allows dhcpcd(8) to at least
try and work with kernel RA on one interface and dhcpcd on another.
Now, we have M_CSUM_TSOv[46] bit in ifp->if_csum_flags_tx when
TSO[46] is enabled for the interface. So we can simply check
whether TSO[46] is required in a packet but missing in the
interface by (sw_csum & M_CSUM_TSOv[46]).
Note that this is a very rare case where TSO[46] is suddenly
turned off during a packet passing b/w TCP and IP.
part of PR kern/53562
OK msaitoh
Add ether_sw_offload_[tr]x: handle TX/RX offload options in software.
Since this violates separation b/w L2 and L3/L4, new files are added
rather than having the routines in sys/net/if_ethersubr.c.
OK msaitoh thorpej
