| Age | Commit message (Collapse) | Author |
|
sys/netinet/tcp_input.c: revision 1.420
PR/kern 55567
fix the data-only fast path. RCV.UP and SND.WL1 could be left behind
on long sequences of data only packets. pull them along to avoid relative
sequence wraps.
consistent with FreeBSD
addresses second failure mode of PR/kern 55567.
pullup to netbsd-8
pullup to netbsd-9
|
|
sys/netinet/tcp_input.c: revision 1.419
Fix fast path for uni directional transfers
pure ACK case:
drag snd_wl2 along so only newer
ACKs can update the window size.
also avoids the state where snd_wl2
is eventually larger than th_ack and thus
blocking the window update mechanism and
the connection gets stuck for a loooong
time in the zero sized send window state.
see PR/kern 55567
ok thorpej@, also found in FreeBSD
|
|
sys/netinet/tcp_input.c: revision 1.418
- always set both ip and ip6, otherwise a kernel assertion can be triggered
- move alignment early so that we do less work
|
|
sys/netinet/tcp_timer.h: revision 1.30
sys/netinet/tcp_input.c: revision 1.415
sys/netinet/tcp_usrreq.c: revision 1.225
sys/netinet/tcp_subr.c: revision 1.283
Clamp tcp timer quantities to reasonable ranges.
|
|
Reported by kUBSan.
|
|
|
|
|
|
|
|
|
|
These functions are defined on unsigned int. The generic name
min/max should not silently truncate to 32 bits on 64-bit systems.
This is purely a name change -- no functional change intended.
HOWEVER! Some subsystems have
#define min(a, b) ((a) < (b) ? (a) : (b))
#define max(a, b) ((a) > (b) ? (a) : (b))
even though our standard name for that is MIN/MAX. Although these
may invite multiple evaluation bugs, these do _not_ cause integer
truncation.
To avoid `fixing' these cases, I first changed the name in libkern,
and then compile-tested every file where min/max occurred in order to
confirm that it failed -- and thus confirm that nothing shadowed
min/max -- before changing it.
I have left a handful of bootloaders that are too annoying to
compile-test, and some dead code:
cobalt ews4800mips hp300 hppa ia64 luna68k vax
acorn32/if_ie.c (not included in any kernels)
macppc/if_gm.c (superseded by gem(4))
It should be easy to fix the fallout once identified -- this way of
doing things fails safe, and the goal here, after all, is to _avoid_
silent integer truncations, not introduce them.
Maybe one day we can reintroduce min/max as type-generic things that
never silently truncate. But we should avoid doing that for a while,
so that existing code has a chance to be detected by the compiler for
conversion to uimin/uimax without changing the semantics until we can
properly audit it all. (Who knows, maybe in some cases integer
truncation is actually intended!)
|
|
|
|
|
|
|
|
The goal was to store in ipre_mlast the last mbuf of the chain, so that
m_cat could be called on it. But it's not needed, since m_cat already
does the equivalent of TRAVERSE itself.
If it were needed, there would be a bug, since we don't call TRAVERSE on
ipre_mlast when creating a new reassembly entry.
|
|
since we used only ipsec_copy_pcbpolicy, and it was a no-op.
Originally we were using ipsec_copy_policy to optimize the IPsec-PCB
cache: when an ACK was received in response to a SYN, we used to copy the
SP cached in the SYN's PCB into the ACK's PCB, so that
ipsec_getpolicybysock could use the cached SP instead of requerying it.
Then we switched to ipsec_copy_pcbpolicy which has always been a no-op. As
a result the SP cached in the SYN was/is not copied in the ACK, and the
first call to ipsec_getpolicybysock had to query the SP and cache it
itself. It's not totally clear to me why this change was made.
But it has been this way for years, and after a conversation with Ryota
Ozaki it turns out the optimization is not valid anymore due to
MP-ification, so it won't be re-enabled.
ok ozaki-r@
|
|
'ip6' branch is never taken. As a result we log garbage on IPv6 packets.
Use ip_v instead.
|
|
functions returns 1 when the buffers are equal, contrary to memcmp, hence
the !.
|
|
|
|
was being developed, but it's irrelevant today. Makes the code clearer.
|
|
|
|
|
|
a tragic bug, because it happens only on sockets with debug enabled.
|
|
|
|
|
|
m->m_pkthdr.len - sizeof(struct tcphdr) - optlen - hlen
= m->m_pkthdr.len - (sizeof(struct tcphdr) + optlen + hlen)
= m->m_pkthdr.len - [tcp_len]
= toff
|
|
* Replace idiotic diagnostic check by KASSERT. max_linkhdr+tlen<=MCLBYTES
is a widespread assumption.
* Improve initialization of 'tp'.
* Put panics in dead branches.
* Merge two switches.
|
|
|
|
|
|
|
|
use NULL for pointers, and add {}s to prevent confusion.
|
|
even IPv4 places that are not covered here.
|
|
|
|
tlen while it doesn't.
|
|
|
|
need to checksum twice.
Then call tcp_fields_to_host a bit earlier, so that we don't need to call
it in each branch.
|
|
It was intended as an optimization, but it increases the attack surface:
the IPsec policy is not enforced on RST packets when the socket is in the
LISTEN state, and an (unauthenticated) attacker could jam the connection
between two IPsec hosts by sending RST packets between the client's SYN
and ACK packets.
Discussed with ozaki-r@.
|
|
|
|
already increases it. IPSEC6_STATINC is now unused, so remove it too.
|
|
While here fix misleading comment.
ok ozaki-r@
|
|
|
|
|
|
freeing it, so free in the caller instead.
|
|
the beginning of the function.
|
|
we're leaking 'ipopts'. (Harmless, since TCP_SIGNATURE is disabled.)
|
|
|
|
all the time, and not just when they are SYNs.
The IPv6 multicast check is already done earlier, so this block of code
can be removed.
|
|
the now-unused multicast detection code. It couldn't have been correct on
IPv6, since multicast packets are kicked at the beginning of the function.
|
|
af == AF_INET || af == AF_INET6.
|
|
|
|
are useless, because the IPv6 entry point (ip6_input) already performs
them.
The checks were first added in the protocol functions:
Wed Dec 22 04:03:02 1999 UTC (18 years, 1 month ago) by itojun
"drop IPv6 packets with v4 mapped address on src/dst. they are illegal
and may be used to fool IPv6 implementations (by using ::ffff:127.0.0.1 as
source you may be able to pretend the packet is from local node)"
Shortly afterwards they were also added in the IPv6 entry point, but
where not removed from the protocol functions:
Mon Jan 31 10:33:22 2000 UTC (18 years ago) by itojun
"be proactive about malicious packet on the wire. we fear that v4 mapped
address to be used as a tool to hose security filters (like bypassing
"local host only" filter by using ::ffff:127.0.0.1)."
OpenBSD did the same a few months ago. FreeBSD has never had these checks.
|