Otherwise if ln_state != ND6_LLINFO_INCOMPLETE and the is no lladdr
and this message was solicited then ln_state is set to ND6_LLINFO_REACHABLE
which could then cause a panic in nd6_resolve().
If ln_state > ND6_LLINFO_INCOMPLETE then it's assumed we have a lladdr.
Potentially this could have been triggered by the introduction of
ND6_LLINFO_PURGE in nd6.c r1.143 but also by the re-introduction of
ND6_LLINFO_INCOMPLETE in nd6.c r1.263.
Depending on the timing, it's technically possible to receive such
a message after the llentry is created with ND6_LLINFO_NOSTATE.
The primary issue was that in revision 1.79 a check was added in the
nd6_defrouter_select() search loop to ignore the entry if RA processing
is enabled on its interface. In practice this results in all entries
being ignored.
This fix reverses the condition, so that an entry is ignored when RA
processing is NOT enabled on its interface. Further, the entry is
only ignored for being selected as the default router. The currently
installed router must be identified regardless of the (current) status
of its interface, so that we can delete the route before installing a
new one.
I also added error logging when adding or deleting a route fails. This
should help the administrator (or kernel developer) in noticing possible
problems.
Finally, if deleting a route fails, the corresponding default route
entry no longer has its "installed" flag cleared, so that deletion will
be retried. At a minimum, this will cause repeated messages about the
failed deletion as opposed to only getting repeated messages about the
installation of a new default route failing.
Fixes PR kern/55091 and also PR bin/54997 as far as the behaviour
observed with ndp(8).
Rip6 entry point could see a garbage Hop6 option.
Not a big issue, since it's a clean panic only triggerable if the socket
has the IN6P_DSTOPTS/IN6P_RTHDR option.
Reported-by: syzbot+3b07b3511b4ceb8bf1e2@syzkaller.appspotmail.com
New sysctl node "net.inet6.ip6.gifpmtu" means
- 0 (default)
Fragment by IPV6_MMTU. All packets reach the destination certainly,
however the long packet performance is poor.
This is same behavior as before.
- 1
Fragment by outer interface's MTU. The long packet performance would
be good, however the packets may be dropped in some network paths
whose path MTU less than the interface's MTU.
- others
undefined yet
New sysctl node "net.interfaces.gif*.pmtu" means
- -1 (default)
Use system default value (net.inet6.ip6.gifpmtu).
- 0
Fragment by IPV6_MMTU for this gif(4) tunnel.
- 1
Fragment by outer interface's MTU for this gif(4) tunnel.
- others
undefined yet
See RFC4459 for more information and other solutions.
ip6_temp_preferred_lifetime is used to calculate an interval period to
regenerate temporary addresse by
TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE - DESYNC_FACTOR
as per RFC 3041 3.5. So it must be greater than (REGEN_ADVANCE +
DESYNC_FACTOR), otherwise it will be negative and go wrong, for example
KASSERT(to_ticks >= 0) in callout_schedule_locked fails.
- Move the related functions to where in6_tmpaddrtimer_ch exists
- Hide global variable in6_tmpaddrtimer_ch
- Rename ip6_init2 to in6_tmpaddrtimer_init
- Reduce callers of callout_reset
- Use callout_schedule
The original code initialized each component in non-init functions such as
arp_dad_start and nd6_dad_find, conditionally based on a global flag for each.
However, it was racy because the flag and the code around it were not
protected by a lock and could cause a kernel panic at worst.
Fix the issue by initializing the components in bootup as usual.
sys/netinet6/scope6.c:480:6,
member access within misaligned address 0xffff9457bc441286 for type
'struct in6_addr' which requires 4 byte alignment
This issue is caused by accessing non-__packed struct in __packed.
This is a[always?] false-positive reported by the sanitizer and there is no
clear non-invasive approach to handle this, without changing ABI of long
term existing code.
Reported-by: syzbot+b53a9bcf030288081e65@syzkaller.appspotmail.com
percpu(9) has a certain memory storage for each CPU and provides it by the piece
to users. If the storages went short, percpu(9) enlarges them by allocating new
larger memory areas, replacing old ones with them and destroying the old ones.
A percpu storage referenced by a pointer gotten via percpu_getref can be
destroyed by the mechanism after a running thread sleeps even if percpu_putref
has not been called.
Using rtcache, i.e., packet processing, typically involves sleepable operations
such as rwlock so we must avoid dereferencing a rtcache that is directly stored
in a percpu storage during packet processing. Address this situation by having
just a pointer to a rtcache in a percpu storage instead.
Reviewed by ozaki-r@ and yamaguchi@
percpu(9) has a certain memory storage for each CPU and provides it by the piece
to users. If the storages went short, percpu(9) enlarges them by allocating new
larger memory areas, replacing old ones with them and destroying the old ones.
A percpu storage referenced by a pointer gotten via percpu_getref can be
destroyed by the mechanism after a running thread sleeps even if percpu_putref
has not been called.
Using rtcache, i.e., packet processing, typically involves sleepable operations
such as rwlock so we must avoid dereferencing a rtcache that is directly stored
in a percpu storage during packet processing. Address this situation by having
just a pointer to a rtcache in a percpu storage instead.
Reviewed by knakahara@ and yamaguchi@
----------------------------
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.
