frag6: don't use spin mutex for frag6_lock

frag6_lock is held during sending a packet (icmp6_error), so we must
not use a spin mutex because we can acquire sleep locks on sending
a packet.

Also we

frag6: don't use spin mutex for frag6_lock

frag6_lock is held during sending a packet (icmp6_error), so we must
not use a spin mutex because we can acquire sleep locks on sending
a packet.

Also we don't need to use spin mutex for frag6_lock anymore because
frag6_lock is now not used from hardware interrupt context.

show more ...

Get rid of unnecessary NULL checks for rt_ifa and ifa_ifp

They are always non-NULL nowadays.

When reassembling IPv4/IPv6 packets, ensure each fragment has been subject
to the same IPsec processing. That is to say, that all fragments are ESP,
or AH, or AH+ESP, or none.

The reassembly mechani

When reassembling IPv4/IPv6 packets, ensure each fragment has been subject
to the same IPsec processing. That is to say, that all fragments are ESP,
or AH, or AH+ESP, or none.

The reassembly mechanism can be used both on the wire and inside an IPsec
tunnel, so we need to make sure all fragments of a packet were received
on only one side.

Even though I haven't tried, I believe there are configurations where it
would be possible for an attacker to inject an unencrypted fragment into a
legitimate stream of already-decrypted-and-authenticated fragments.

Typically on IPsec gateways with ESP tunnels, where we can encapsulate
fragments (as opposed to the general case, where we fragment encapsulated
data).

Note, for the record: a funnier thing, under IPv4, would be to send a
zero-sized !MFF fragment at the head of the packet, and manage to trigger
an ICMP error; M_DECRYPTED gets lost by the reassembly, and ICMP will reply
with the packet in clear (not encrypted).

show more ...

Rename m_pkthdr_remove -> m_remove_pkthdr, to match the existing naming
convention, eg m_copy_pkthdr and m_move_pkthdr.

Remove now unused net_osdep.h includes, the other BSDs did the same.

Localify global variables, style, and add two XXXs.

Add XXX, using a pool would be better than kmem.

Release the lock a little earlier.

Add XXX. In fact, it would be better, if all the fragments were offloaded,
to quickly recompute the checksum on the fly, and keep it in the mbuf
header.

Remove M_PKTHDR from secondary mbufs when reassembling packets.

This is a real problem, because I found at least one component that relies
on the fact that only the first mbuf has M_PKTHDR: far from

Remove M_PKTHDR from secondary mbufs when reassembling packets.

This is a real problem, because I found at least one component that relies
on the fact that only the first mbuf has M_PKTHDR: far from here, in
m_splithdr, we don't update m->m_pkthdr.len if M_PKTHDR is found in a
secondary mbuf. (The initial intention there was to avoid updating
m_pkthdr.len twice, the assumption was that if M_PKTHDR is set then we're
dealing with the first mbuf.) Therefore, when handling fragmented IPsec
packets (in particular IPv6, IPv4 is a bit more complicated), we may end
up with an incorrect m_pkthdr.len after authentication or decryption. In
the case of ESP, this can lead to a remote crash on this instruction:

m_copydata(m, m->m_pkthdr.len - 3, 3, lastthree);

m_pkthdr.len is bigger than the actual mbuf chain.

It seems possible to me to trigger this bug even if you don't have the ESP
key, because the fragmentation part is outside of the encrypted ESP
payload.

So if you MITM the target, and intercept an incoming ESP packet (which you
can't decrypt), you should be able to forge a new specially-crafted,
fragmented packet and stuff the ESP payload (still encrypted, as you
intercepted it) into it. The decryption succeeds and the target crashes.

show more ...

Rename back to ip6af_mff. It was actually clearer than ip6af_more.

Fix a buffer overflow in ip6_get_prevhdr. Doing

mtod(m, char *) + len

is wrong, an option is allowed to be located in another mbuf of the chain.
If the offset of an option within the chain is bigg

Fix a buffer overflow in ip6_get_prevhdr. Doing

mtod(m, char *) + len

is wrong, an option is allowed to be located in another mbuf of the chain.
If the offset of an option within the chain is bigger than the length of
the first mbuf in that chain, we are reading/writing one byte of packet-
controlled data beyond the end of the first mbuf.

The length of this first mbuf depends on the layout the network driver
chose. In the most difficult case, it will allocate a 2KB cluster, which
is bigger than the Ethernet MTU.

But there is at least one way of exploiting this case: by sending a
special combination of nested IPv6 fragments, the packet can control a
good bunch of 'len'. By luck, the memory pool containing clusters does not
embed the pool header in front of the items, so it is not straightforward
to predict what is located at 'mtod(m, char *) + len'.

However, by sending offending fragments in a loop, it is possible to
crash the kernel - at some point we will hit important data structures.

As far as I can tell, PF protects against this difficult case, because
it kicks nested fragments. NPF does not protect against this. IPF I don't
know.

Then there are the more easy cases, if the MTU is bigger than a cluster,
or if the network driver did not allocate a cluster, or perhaps if the
fragments are received via a tunnel; I haven't investigated these cases.

Change ip6_get_prevhdr so that it returns an offset in the chain, and
always use IP6_EXTHDR_GET to get a writable pointer. IP6_EXTHDR_GET
leaves M_PKTHDR untouched.

This place is still fragile.

show more ...

Kick zero-sized fragments. We can't allow them to enter; two fragments
could be put at the same offset.

Remove outdated comment and fix typo.

Several changes:

* Move the structure definitions into frag6.c, they should not be used
elsewhere.

* Rename ip6af_mff -> ip6af_more, and switch it to bool, easier to
understand.

* Remove

Several changes:

* Move the structure definitions into frag6.c, they should not be used
elsewhere.

* Rename ip6af_mff -> ip6af_more, and switch it to bool, easier to
understand.

* Remove IP6_REASS_MBUF, no point in keeping this.

* Remove ip6q_arrive and ip6q_nxtp, unused.

* Style.

show more ...

Provide macros for softnet_lock and KERNEL_LOCK hiding NET_MPSAFE switch

It reduces C&P codes such as "#ifndef NET_MPSAFE KERNEL_LOCK(1, NULL); ..."
scattered all over the source code and makes it e

Provide macros for softnet_lock and KERNEL_LOCK hiding NET_MPSAFE switch

It reduces C&P codes such as "#ifndef NET_MPSAFE KERNEL_LOCK(1, NULL); ..."
scattered all over the source code and makes it easy to identify remaining
KERNEL_LOCK and/or softnet_lock that are held even if NET_MPSAFE.

No functional change

show more ...

Tweak softnet_lock and NET_MPSAFE

- Don't hold softnet_lock in some functions if NET_MPSAFE
- Add softnet_lock to sysctl_net_inet_icmp_redirtimeout
- Add softnet_lock to expire_upcalls of ip_mroute.

Tweak softnet_lock and NET_MPSAFE

- Don't hold softnet_lock in some functions if NET_MPSAFE
- Add softnet_lock to sysctl_net_inet_icmp_redirtimeout
- Add softnet_lock to expire_upcalls of ip_mroute.c
- Restore softnet_lock for in{,6}_pcbpurgeif{,0} if NET_MPSAFE
- Mark some softnet_lock for future work

show more ...

Get rid of unnecessary header inclusions

Add rtcache_unref to release points of rtentry stemming from rtcache

In the MP-safe world, a rtentry stemming from a rtcache can be freed at any
points. So we need to protect rtentries somehow say b

Add rtcache_unref to release points of rtentry stemming from rtcache

In the MP-safe world, a rtentry stemming from a rtcache can be freed at any
points. So we need to protect rtentries somehow say by reference couting or
passive references. Regardless of the method, we need to call some release
function of a rtentry after using it.

The change adds a new function rtcache_unref to release a rtentry. At this
point, this function does nothing because for now we don't add a reference
to a rtentry when we get one from a rtcache. We will add something useful
in a further commit.

This change is a part of changes for MP-safe routing table. It is separated
to avoid one big change that makes difficult to debug by bisecting.

show more ...

Reduce the number of return points of frag6_input

No functional change.

Don't use new as a variable name.

draft-gont-6man-ipv6-atomic-fragment-00 is now RFC 6949 (Loganaden Velvindron
logan at elandsys dot com)

Loganaden Velvindron:

From "http://tools.ietf.org/html/draft-ietf-6man-ipv6-atomic-fragments-00":

A host that receives an IPv6 packet which includes a Fragment
Header with the "Fragment Offset" equ

Loganaden Velvindron:

From "http://tools.ietf.org/html/draft-ietf-6man-ipv6-atomic-fragments-00":

A host that receives an IPv6 packet which includes a Fragment
Header with the "Fragment Offset" equal to 0 and the "M" bit equal
to 0 MUST process such packet in isolation from any other packets/
fragments, even if such packets/fragments contain the same set
{IPV6 Source Address, IPv6 Destination Address, Fragment
Identification}. That is, the Fragment Header of "atomic
fragments" should be removed by the receiving host, and the
resulting packet should be processed as a non-fragmented IPv6
datagram. Additionally, any fragments already queued with the
same set {IPV6 Source Address, IPv6 Destination Address, Fragment
Identification} should not be discarded upon receipt of the
"colliding" IPv6 atomic fragment, since IPv6 atomic fragments do
not really interfere with "normal" fragmented traffic.

show more ...

Remove the wrapper of frag6_input(), restore the behaviour changed in r1.50.
Fix ip6_reass_packet() wrapper used by NPF. Remove #if 0 code for handling
overlaping fragments - IPv6 desupported them a

Remove the wrapper of frag6_input(), restore the behaviour changed in r1.50.
Fix ip6_reass_packet() wrapper used by NPF. Remove #if 0 code for handling
overlaping fragments - IPv6 desupported them anyway. Convert to kmem(9).

show more ...

- fix offsetof usage, and redundant defines
- kill pointer casts to 0