frag6_input(): must always decrement counter when dropping fragment
Currently frag6_input() does not decrement counter in one case:
- it is processing fragment with offset 0 which arrives after
the last fragment (fragment with max. offset)
- there are more IPv6 extension headers between IPv6 header
and IPv6 fragment header
- re-assembled packet exceeds IPV6_MAXPACKET size limit
if conditions above are met, then fragment gets dropped without
decrementing counters. This commit fixes that.
The issue was pointed out by Frank Denis.
OK bluhm@
Make __pledge_open(2) of /etc/localtime and /usr/share/zoneinfo much
more strict. If /etc/localtime is a symbolic link, allow one translation
which must land cleanly in /usr/share/zoneinfo (.. is checked for) otherwise
error with EACCES. In /usr/share/zoneinfo, do not allow symbolic links and
error with ELOOP.
Alfredo Ortega observed the non-strict handling, but agrees no specific
exploitability exists. Changing this took almost a month with many
discarded prototypes.
ok beck dgl
If the main process receives an oversized passwd or group entry message from
the ldap client process, discard it rather than overflowing the struct
idm_req on the stack.
Pointed out by Frank Denis
ok claudio@
Rework the re-evaluation of a prefix if PREFIX_FLAG_FILTERED changed.
The fix committed in rev 1.291 is not quite right. The problem is that
prefix_evaluate() uses prefix_best() which calls prefix_eligible().
It is wrong to alter the eligible state of a prefix while it is still
on the rib list.
Instead remove the prefix first, toggle the state, then readd it again.
Even though prefix_evaluate() is called twice the code complexity is
about the same since the 2 calls only do half the work.
OK tb@