The NetBSD Project

CVS log for src/sys/netinet/ip_reass.c

[BACK] Up to [cvs.NetBSD.org] / src / sys / netinet

Request diff between arbitrary revisions

Default branch: MAIN

Revision 1.23 / (download) - annotate - [select for diffs], Tue May 31 08:43:16 2022 UTC (22 months, 2 weeks ago) by andvar
Branch: MAIN
CVS Tags: thorpej-ifq-base, thorpej-ifq, thorpej-altq-separation-base, thorpej-altq-separation, netbsd-10-base, netbsd-10-0-RELEASE, netbsd-10-0-RC6, netbsd-10-0-RC5, netbsd-10-0-RC4, netbsd-10-0-RC3, netbsd-10-0-RC2, netbsd-10-0-RC1, netbsd-10, bouyer-sunxi-drm-base, bouyer-sunxi-drm, HEAD
Changes since 1.22: +3 -3 lines
Diff to previous 1.22 (colored) to selected 1.11.8.7 (colored) 

fix various typos in comments, documentation and messages.

Revision 1.22 / (download) - annotate - [select for diffs], Wed Feb 16 22:00:56 2022 UTC (2 years, 2 months ago) by andvar
Branch: MAIN
Changes since 1.21: +3 -3 lines
Diff to previous 1.21 (colored) to selected 1.11.8.7 (colored) 

fix various typos, mainly in comments.

Revision 1.17.2.1 / (download) - annotate - [select for diffs], Mon Jun 10 22:09:47 2019 UTC (4 years, 10 months ago) by christos
Branch: phil-wifi
Changes since 1.17: +45 -48 lines
Diff to previous 1.17 (colored) next main 1.18 (colored) to selected 1.11.8.7 (colored) 

Sync with HEAD

Revision 1.13.2.6 / (download) - annotate - [select for diffs], Sat Oct 20 06:58:46 2018 UTC (5 years, 6 months ago) by pgoyette
Branch: pgoyette-compat
CVS Tags: pgoyette-compat-merge-20190127
Changes since 1.13.2.5: +3 -2 lines
Diff to previous 1.13.2.5 (colored) to branchpoint 1.13 (colored) next main 1.14 (colored) to selected 1.11.8.7 (colored) 

Sync with head

Revision 1.11.8.7 / (download) - annotate - [selected], Wed Oct 17 13:38:04 2018 UTC (5 years, 6 months ago) by martin
Branch: netbsd-8
CVS Tags: netbsd-8-2-RELEASE, netbsd-8-1-RELEASE, netbsd-8-1-RC1
Changes since 1.11.8.6: +42 -46 lines
Diff to previous 1.11.8.6 (colored) to branchpoint 1.11 (colored) next main 1.12 (colored) 

Pull up following revision(s) (requested by maxv in ticket #1045):

	sys/netinet/ip_reass.c: revision 1.19-1.21

Hold ip_off and ip_len in the fragment entry, instead of always reading
the associated mbuf (and converting to host order). This reduces the
cache/TLB misses when processing long lists.

 -

Kick fragments that would introduce several !MFFs in a reassembly chain.

The problem arises if we receive three fragments of the kind
        3.  A -> has MFF
        1.  B -> doesn't have MFF
        2.  C -> doesn't have MFF

Because of the received order B->C->A, we don't see that B is !MFF, and
therefore that there is a problem in this chain.

Now we do two checks, and drop us if:

 * there is a fragment preceding us, and this fragment is !MFF, or
 * there is a fragment following us, and we are !MFF

Spotted a long time ago.

 -

Force ip_off to zero when the reassembly is complete. This was lost in my
rev1.19 - before that the IP struct was clobbered for the reassembly, but
it actually implicitly guaranteed that the first fragment of the packet
would end up with ip_off = 0, and this was a desired behavior.

Revision 1.21 / (download) - annotate - [select for diffs], Fri Oct 12 05:41:18 2018 UTC (5 years, 6 months ago) by maxv
Branch: MAIN
CVS Tags: thorpej-i2c-spi-conf2-base, thorpej-i2c-spi-conf2, thorpej-i2c-spi-conf-base, thorpej-i2c-spi-conf, thorpej-futex2-base, thorpej-futex2, thorpej-futex-base, thorpej-futex, thorpej-cfargs2-base, thorpej-cfargs2, thorpej-cfargs-base, thorpej-cfargs, phil-wifi-20200421, phil-wifi-20200411, phil-wifi-20200406, phil-wifi-20191119, phil-wifi-20190609, pgoyette-compat-20190127, pgoyette-compat-20190118, pgoyette-compat-1226, pgoyette-compat-1126, pgoyette-compat-1020, netbsd-9-base, netbsd-9-3-RELEASE, netbsd-9-2-RELEASE, netbsd-9-1-RELEASE, netbsd-9-0-RELEASE, netbsd-9-0-RC2, netbsd-9-0-RC1, netbsd-9, isaki-audio2-base, isaki-audio2, is-mlppp-base, is-mlppp, cjep_sun2x-base1, cjep_sun2x-base, cjep_sun2x, cjep_staticlib_x-base1, cjep_staticlib_x-base, cjep_staticlib_x, bouyer-xenpvh-base2, bouyer-xenpvh-base1, bouyer-xenpvh-base, bouyer-xenpvh, ad-namecache-base3, ad-namecache-base2, ad-namecache-base1, ad-namecache-base, ad-namecache
Changes since 1.20: +3 -2 lines
Diff to previous 1.20 (colored) to selected 1.11.8.7 (colored) 

Force ip_off to zero when the reassembly is complete. This was lost in my
rev1.19 - before that the IP struct was clobbered for the reassembly, but
it actually implicitly guaranteed that the first fragment of the packet
would end up with ip_off = 0, and this was a desired behavior.

Revision 1.11.8.6 / (download) - annotate - [select for diffs], Tue Oct 9 09:44:31 2018 UTC (5 years, 6 months ago) by martin
Branch: netbsd-8
Changes since 1.11.8.5: +41 -22 lines
Diff to previous 1.11.8.5 (colored) to branchpoint 1.11 (colored) to selected 1.11.8.7 (colored) 

Back out the following from ticket #1045 by maxv:

	sys/netinet/ip_reass.c		1.19

Faster IPv4 packet reassembly - causes fallout, needs further investigation
(see PR kern/53664)

Revision 1.11.8.5 / (download) - annotate - [select for diffs], Wed Oct 3 17:53:56 2018 UTC (5 years, 6 months ago) by martin
Branch: netbsd-8
Changes since 1.11.8.4: +22 -41 lines
Diff to previous 1.11.8.4 (colored) to branchpoint 1.11 (colored) to selected 1.11.8.7 (colored) 

Pull up following revision(s) (requested by maxv in ticket #1045):

	sys/netinet/ip_reass.c: revision 1.19

Hold ip_off and ip_len in the fragment entry, instead of always reading
the associated mbuf (and converting to host order). This reduces the
cache/TLB misses when processing long lists.

Revision 1.13.2.5 / (download) - annotate - [select for diffs], Sun Sep 30 01:45:56 2018 UTC (5 years, 6 months ago) by pgoyette
Branch: pgoyette-compat
Changes since 1.13.2.4: +41 -46 lines
Diff to previous 1.13.2.4 (colored) to branchpoint 1.13 (colored) to selected 1.11.8.7 (colored) 

Ssync with HEAD

Revision 1.11.8.4 / (download) - annotate - [select for diffs], Thu Sep 27 15:07:34 2018 UTC (5 years, 6 months ago) by martin
Branch: netbsd-8
Changes since 1.11.8.3: +21 -8 lines
Diff to previous 1.11.8.3 (colored) to branchpoint 1.11 (colored) to selected 1.11.8.7 (colored) 

Pull up following revision(s) (requested by maxv in ticket #1041):

	sys/netinet/ip_reass.c: revision 1.17 (patch)
	sys/netinet6/frag6.c: revision 1.74 (patch)

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).

Revision 1.20 / (download) - annotate - [select for diffs], Mon Sep 17 08:11:27 2018 UTC (5 years, 7 months ago) by maxv
Branch: MAIN
CVS Tags: pgoyette-compat-0930
Changes since 1.19: +21 -7 lines
Diff to previous 1.19 (colored) to selected 1.11.8.7 (colored) 

Kick fragments that would introduce several !MFFs in a reassembly chain.

The problem arises if we receive three fragments of the kind

	3.  A -> has MFF
	1.  B -> doesn't have MFF
	2.  C -> doesn't have MFF

Because of the received order B->C->A, we don't see that B is !MFF, and
therefore that there is a problem in this chain.

Now we do two checks, and drop us if:

 * there is a fragment preceding us, and this fragment is !MFF, or
 * there is a fragment following us, and we are !MFF

Spotted a long time ago.

Revision 1.19 / (download) - annotate - [select for diffs], Mon Sep 17 06:01:36 2018 UTC (5 years, 7 months ago) by maxv
Branch: MAIN
Changes since 1.18: +22 -41 lines
Diff to previous 1.18 (colored) to selected 1.11.8.7 (colored) 

Hold ip_off and ip_len in the fragment entry, instead of always reading
the associated mbuf (and converting to host order). This reduces the
cache/TLB misses when processing long lists.

Revision 1.13.2.4 / (download) - annotate - [select for diffs], Sat Jul 28 04:38:10 2018 UTC (5 years, 8 months ago) by pgoyette
Branch: pgoyette-compat
Changes since 1.13.2.3: +5 -4 lines
Diff to previous 1.13.2.3 (colored) to branchpoint 1.13 (colored) to selected 1.11.8.7 (colored) 

Sync with HEAD

Revision 1.18 / (download) - annotate - [select for diffs], Tue Jul 10 15:46:58 2018 UTC (5 years, 9 months ago) by maxv
Branch: MAIN
CVS Tags: pgoyette-compat-0906, pgoyette-compat-0728
Changes since 1.17: +5 -4 lines
Diff to previous 1.17 (colored) to selected 1.11.8.7 (colored) 

Remove the second argument from ip_reass_packet(). We want the IP header
on the mbuf, not elsewhere. Simplifies the NPF reassembly code a little.
No real functional change.

Revision 1.13.2.3 / (download) - annotate - [select for diffs], Mon May 21 04:36:16 2018 UTC (5 years, 11 months ago) by pgoyette
Branch: pgoyette-compat
Changes since 1.13.2.2: +22 -9 lines
Diff to previous 1.13.2.2 (colored) to branchpoint 1.13 (colored) to selected 1.11.8.7 (colored) 

Sync with HEAD

Revision 1.17 / (download) - annotate - [select for diffs], Tue May 15 19:16:38 2018 UTC (5 years, 11 months ago) by maxv
Branch: MAIN
CVS Tags: phil-wifi-base, pgoyette-compat-0625, pgoyette-compat-0521
Branch point for: phil-wifi
Changes since 1.16: +21 -8 lines
Diff to previous 1.16 (colored) to selected 1.11.8.7 (colored) 

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).

Revision 1.16 / (download) - annotate - [select for diffs], Thu May 3 07:25:49 2018 UTC (5 years, 11 months ago) by maxv
Branch: MAIN
Changes since 1.15: +3 -3 lines
Diff to previous 1.15 (colored) to selected 1.11.8.7 (colored) 

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

Revision 1.13.2.2 / (download) - annotate - [select for diffs], Mon Apr 16 02:00:08 2018 UTC (6 years ago) by pgoyette
Branch: pgoyette-compat
Changes since 1.13.2.1: +3 -3 lines
Diff to previous 1.13.2.1 (colored) to branchpoint 1.13 (colored) to selected 1.11.8.7 (colored) 

Sync with HEAD, resolve some conflicts

Revision 1.15 / (download) - annotate - [select for diffs], Wed Apr 11 07:15:12 2018 UTC (6 years ago) by maxv
Branch: MAIN
CVS Tags: pgoyette-compat-0502, pgoyette-compat-0422, pgoyette-compat-0415
Changes since 1.14: +3 -3 lines
Diff to previous 1.14 (colored) to selected 1.11.8.7 (colored) 

Add 'static', like the prototype.

Revision 1.11.8.3 / (download) - annotate - [select for diffs], Mon Apr 9 16:40:07 2018 UTC (6 years ago) by martin
Branch: netbsd-8
CVS Tags: netbsd-8-0-RELEASE, netbsd-8-0-RC2, netbsd-8-0-RC1
Changes since 1.11.8.2: +3 -3 lines
Diff to previous 1.11.8.2 (colored) to branchpoint 1.11 (colored) to selected 1.11.8.7 (colored) 

Additionally pull up the following revision for ticket #668,
requested by ozaki-r:

	sys/netinet/ip_reass.c 1.13

Change the error stat from IP_STAT_BADFRAGS to IP_STAT_TOOLONG. The
ping_of_death ATF test expects this counter to get increased.

Revision 1.11.8.2 / (download) - annotate - [select for diffs], Thu Apr 5 14:33:41 2018 UTC (6 years ago) by martin
Branch: netbsd-8
Changes since 1.11.8.1: +5 -3 lines
Diff to previous 1.11.8.1 (colored) to branchpoint 1.11 (colored) to selected 1.11.8.7 (colored) 

Pull up following revision(s) (requested by maxv in ticket #695):

	sys/kern/uipc_mbuf.c: revision 1.182
	sys/netinet6/frag6.c: revision 1.67
	sys/netinet/ip_reass.c: revision 1.14
	sys/sys/mbuf.h: revision 1.179

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.

Revision 1.9.8.1 / (download) - annotate - [select for diffs], Thu Apr 5 11:53:02 2018 UTC (6 years ago) by martin
Branch: netbsd-7-0
Changes since 1.9: +5 -3 lines
Diff to previous 1.9 (colored) next main 1.10 (colored) to selected 1.11.8.7 (colored) 

Pull up following revision(s) (requested by maxv in ticket #1594):

	sys/kern/uipc_mbuf.c: revision 1.182
	sys/netinet6/frag6.c: revision 1.67
	sys/netinet/ip_reass.c: revision 1.14
	sys/sys/mbuf.h: revision 1.179

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.

Revision 1.9.12.1 / (download) - annotate - [select for diffs], Thu Apr 5 11:50:17 2018 UTC (6 years ago) by martin
Branch: netbsd-7-1
Changes since 1.9: +5 -3 lines
Diff to previous 1.9 (colored) next main 1.10 (colored) to selected 1.11.8.7 (colored) 

Pull up following revision(s) (requested by maxv in ticket #1594):

	sys/kern/uipc_mbuf.c: revision 1.182
	sys/netinet6/frag6.c: revision 1.67
	sys/netinet/ip_reass.c: revision 1.14
	sys/sys/mbuf.h: revision 1.179

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.

Revision 1.9.4.1 / (download) - annotate - [select for diffs], Thu Apr 5 11:48:13 2018 UTC (6 years ago) by martin
Branch: netbsd-7
CVS Tags: netbsd-7-2-RELEASE
Changes since 1.9: +5 -3 lines
Diff to previous 1.9 (colored) next main 1.10 (colored) to selected 1.11.8.7 (colored) 

Pull up following revision(s) (requested by maxv in ticket #1594):

	sys/kern/uipc_mbuf.c: revision 1.182
	sys/netinet6/frag6.c: revision 1.67
	sys/netinet/ip_reass.c: revision 1.14
	sys/sys/mbuf.h: revision 1.179

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.

Revision 1.11.8.1 / (download) - annotate - [select for diffs], Fri Mar 30 11:10:14 2018 UTC (6 years ago) by martin
Branch: netbsd-8
Changes since 1.11: +7 -2 lines
Diff to previous 1.11 (colored) to selected 1.11.8.7 (colored) 

Pull up following revision(s) (requested by maxv in ticket #668):
	sys/netinet/ip_reass.c: revision 1.12

Add one more check in ip_reass_packet(): make sure that the end of each
fragment does not exceed IP_MAXPACKET.

In ip_reass(), we only check the final length of the reassembled packet
against IP_MAXPACKET.

But there is an integer overflow that can happen a little earlier. We
are doing:

        i = ntohs(p->ipqe_ip->ip_off) + ntohs(p->ipqe_ip->ip_len) -
            ntohs(ip->ip_off);
        [...]
        ip->ip_off = htons(ntohs(ip->ip_off) + i);

It is possible that

        ntohs(p->ipqe_ip->ip_off) + ntohs(p->ipqe_ip->ip_len) > 65535

so the computation of ip_off wraps to zero. This breaks an assumption in
the reassembler - it expects the list of fragments to be ordered by
offset, and here it's not ordered anymore. (Un)Fortunately I couldn't
turn this into anything exploitable.

With the new check, it is guaranteed that ip_off+ip_len<=65535.

Revision 1.13.2.1 / (download) - annotate - [select for diffs], Thu Mar 15 09:12:06 2018 UTC (6 years, 1 month ago) by pgoyette
Branch: pgoyette-compat
Changes since 1.13: +5 -3 lines
Diff to previous 1.13 (colored) to selected 1.11.8.7 (colored) 

Synch with HEAD

Revision 1.14 / (download) - annotate - [select for diffs], Fri Mar 9 11:57:38 2018 UTC (6 years, 1 month ago) by maxv
Branch: MAIN
CVS Tags: pgoyette-compat-0407, pgoyette-compat-0330, pgoyette-compat-0322, pgoyette-compat-0315
Changes since 1.13: +5 -3 lines
Diff to previous 1.13 (colored) to selected 1.11.8.7 (colored) 

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.

Revision 1.13 / (download) - annotate - [select for diffs], Thu Feb 8 10:03:52 2018 UTC (6 years, 2 months ago) by maxv
Branch: MAIN
CVS Tags: pgoyette-compat-base
Branch point for: pgoyette-compat
Changes since 1.12: +3 -3 lines
Diff to previous 1.12 (colored) to selected 1.11.8.7 (colored) 

Change the error stat from IP_STAT_BADFRAGS to IP_STAT_TOOLONG. The
ping_of_death ATF test expects this counter to get increased.

Revision 1.12 / (download) - annotate - [select for diffs], Tue Feb 6 15:48:02 2018 UTC (6 years, 2 months ago) by maxv
Branch: MAIN
Changes since 1.11: +7 -2 lines
Diff to previous 1.11 (colored) to selected 1.11.8.7 (colored) 

Add one more check in ip_reass_packet(): make sure that the end of each
fragment does not exceed IP_MAXPACKET.

In ip_reass(), we only check the final length of the reassembled packet
against IP_MAXPACKET.

But there is an integer overflow that can happen a little earlier. We
are doing:

	i = ntohs(p->ipqe_ip->ip_off) + ntohs(p->ipqe_ip->ip_len) -
	    ntohs(ip->ip_off);
	[...]
	ip->ip_off = htons(ntohs(ip->ip_off) + i);

It is possible that

	ntohs(p->ipqe_ip->ip_off) + ntohs(p->ipqe_ip->ip_len) > 65535

so the computation of ip_off wraps to zero. This breaks an assumption in
the reassembler - it expects the list of fragments to be ordered by
offset, and here it's not ordered anymore. (Un)Fortunately I couldn't
turn this into anything exploitable.

With the new check, it is guaranteed that ip_off+ip_len<=65535.

Revision 1.8.12.2 / (download) - annotate - [select for diffs], Sun Dec 3 11:39:04 2017 UTC (6 years, 4 months ago) by jdolecek
Branch: tls-maxphys
Changes since 1.8.12.1: +0 -4 lines
Diff to previous 1.8.12.1 (colored) to branchpoint 1.8 (colored) next main 1.9 (colored) to selected 1.11.8.7 (colored) 

update from HEAD

Revision 1.10.2.1 / (download) - annotate - [select for diffs], Mon Mar 20 06:57:50 2017 UTC (7 years, 1 month ago) by pgoyette
Branch: pgoyette-localcount
Changes since 1.10: +2 -5 lines
Diff to previous 1.10 (colored) next main 1.11 (colored) to selected 1.11.8.7 (colored) 

Sync with HEAD

Revision 1.9.6.2 / (download) - annotate - [select for diffs], Sun Feb 5 13:40:59 2017 UTC (7 years, 2 months ago) by skrll
Branch: nick-nhusb
Changes since 1.9.6.1: +2 -5 lines
Diff to previous 1.9.6.1 (colored) to branchpoint 1.9 (colored) next main 1.10 (colored) to selected 1.11.8.7 (colored) 

Sync with HEAD

Revision 1.11 / (download) - annotate - [select for diffs], Wed Jan 11 13:08:29 2017 UTC (7 years, 3 months ago) by ozaki-r
Branch: MAIN
CVS Tags: tls-maxphys-base-20171202, prg-localcount2-base3, prg-localcount2-base2, prg-localcount2-base1, prg-localcount2-base, prg-localcount2, pgoyette-localcount-20170426, pgoyette-localcount-20170320, perseant-stdc-iso10646-base, perseant-stdc-iso10646, nick-nhusb-base-20170825, nick-nhusb-base-20170204, netbsd-8-base, matt-nb8-mediatek-base, matt-nb8-mediatek, jdolecek-ncq-base, jdolecek-ncq, bouyer-socketcan-base1, bouyer-socketcan-base, bouyer-socketcan
Branch point for: netbsd-8
Changes since 1.10: +2 -5 lines
Diff to previous 1.10 (colored) to selected 1.11.8.7 (colored) 

Get rid of unnecessary header inclusions

Revision 1.9.6.1 / (download) - annotate - [select for diffs], Sun May 29 08:44:38 2016 UTC (7 years, 10 months ago) by skrll
Branch: nick-nhusb
Changes since 1.9: +2 -3 lines
Diff to previous 1.9 (colored) to selected 1.11.8.7 (colored) 

Sync with HEAD

Revision 1.10 / (download) - annotate - [select for diffs], Tue Apr 26 08:44:44 2016 UTC (7 years, 11 months ago) by ozaki-r
Branch: MAIN
CVS Tags: pgoyette-localcount-base, pgoyette-localcount-20170107, pgoyette-localcount-20161104, pgoyette-localcount-20160806, pgoyette-localcount-20160726, nick-nhusb-base-20161204, nick-nhusb-base-20161004, nick-nhusb-base-20160907, nick-nhusb-base-20160529, localcount-20160914
Branch point for: pgoyette-localcount
Changes since 1.9: +2 -3 lines
Diff to previous 1.9 (colored) to selected 1.11.8.7 (colored) 

Sweep unnecessary route.h inclusions

Revision 1.8.12.1 / (download) - annotate - [select for diffs], Wed Aug 20 00:04:35 2014 UTC (9 years, 8 months ago) by tls
Branch: tls-maxphys
Changes since 1.8: +2 -7 lines
Diff to previous 1.8 (colored) to selected 1.11.8.7 (colored) 

Rebase to HEAD as of a few days ago.

Revision 1.8.2.1 / (download) - annotate - [select for diffs], Thu May 22 11:41:09 2014 UTC (9 years, 11 months ago) by yamt
Branch: yamt-pagecache
Changes since 1.8: +2 -7 lines
Diff to previous 1.8 (colored) next main 1.9 (colored) to selected 1.11.8.7 (colored) 

sync with head.

for a reference, the tree before this commit was tagged
as yamt-pagecache-tag8.

this commit was splitted into small chunks to avoid
a limitation of cvs.  ("Protocol error: too many arguments")

Revision 1.8.16.1 / (download) - annotate - [select for diffs], Sun May 18 17:46:13 2014 UTC (9 years, 11 months ago) by rmind
Branch: rmind-smpnet
Changes since 1.8: +2 -7 lines
Diff to previous 1.8 (colored) next main 1.9 (colored) to selected 1.11.8.7 (colored) 

sync with head

Revision 1.9 / (download) - annotate - [select for diffs], Tue Feb 25 18:30:12 2014 UTC (10 years, 1 month ago) by pooka
Branch: MAIN
CVS Tags: yamt-pagecache-base9, tls-maxphys-base, tls-earlyentropy-base, tls-earlyentropy, rmind-smpnet-nbase, rmind-smpnet-base, riastradh-xf86-video-intel-2-7-1-pre-2-21-15, riastradh-drm2-base3, nick-nhusb-base-20160422, nick-nhusb-base-20160319, nick-nhusb-base-20151226, nick-nhusb-base-20150921, nick-nhusb-base-20150606, nick-nhusb-base-20150406, nick-nhusb-base, netbsd-7-nhusb-base-20170116, netbsd-7-nhusb-base, netbsd-7-nhusb, netbsd-7-base, netbsd-7-1-RELEASE, netbsd-7-1-RC2, netbsd-7-1-RC1, netbsd-7-1-2-RELEASE, netbsd-7-1-1-RELEASE, netbsd-7-0-RELEASE, netbsd-7-0-RC3, netbsd-7-0-RC2, netbsd-7-0-RC1, netbsd-7-0-2-RELEASE, netbsd-7-0-1-RELEASE
Branch point for: nick-nhusb, netbsd-7-1, netbsd-7-0, netbsd-7
Changes since 1.8: +2 -7 lines
Diff to previous 1.8 (colored) to selected 1.11.8.7 (colored) 

Ensure that the top level sysctl nodes (kern, vfs, net, ...) exist before
the sysctl link sets are processed, and remove redundancy.

Shaves >13kB off of an amd64 GENERIC, not to mention >1k duplicate
lines of code.

Revision 1.8 / (download) - annotate - [select for diffs], Mon Jun 27 00:45:50 2011 UTC (12 years, 9 months ago) by enami
Branch: MAIN
CVS Tags: yamt-pagecache-tag8, yamt-pagecache-base8, yamt-pagecache-base7, yamt-pagecache-base6, yamt-pagecache-base5, yamt-pagecache-base4, yamt-pagecache-base3, yamt-pagecache-base2, yamt-pagecache-base, riastradh-drm2-base2, riastradh-drm2-base1, riastradh-drm2-base, riastradh-drm2, netbsd-6-base, netbsd-6-1-RELEASE, netbsd-6-1-RC4, netbsd-6-1-RC3, netbsd-6-1-RC2, netbsd-6-1-RC1, netbsd-6-1-5-RELEASE, netbsd-6-1-4-RELEASE, netbsd-6-1-3-RELEASE, netbsd-6-1-2-RELEASE, netbsd-6-1-1-RELEASE, netbsd-6-1, netbsd-6-0-RELEASE, netbsd-6-0-RC2, netbsd-6-0-RC1, netbsd-6-0-6-RELEASE, netbsd-6-0-5-RELEASE, netbsd-6-0-4-RELEASE, netbsd-6-0-3-RELEASE, netbsd-6-0-2-RELEASE, netbsd-6-0-1-RELEASE, netbsd-6-0, netbsd-6, matt-nb6-plus-nbase, matt-nb6-plus-base, matt-nb6-plus, khorben-n900, jmcneill-usbmp-pre-base2, jmcneill-usbmp-base9, jmcneill-usbmp-base8, jmcneill-usbmp-base7, jmcneill-usbmp-base6, jmcneill-usbmp-base5, jmcneill-usbmp-base4, jmcneill-usbmp-base3, jmcneill-usbmp-base2, jmcneill-usbmp-base10, jmcneill-usbmp-base, jmcneill-usbmp, jmcneill-audiomp3-base, jmcneill-audiomp3, agc-symver-base, agc-symver
Branch point for: yamt-pagecache, tls-maxphys, rmind-smpnet
Changes since 1.7: +3 -3 lines
Diff to previous 1.7 (colored) to selected 1.11.8.7 (colored) 

Don't increment ip_nfragpackets when failed to allocate fragment queue.
No one will decrement it on such case.

Revision 1.7.6.2 / (download) - annotate - [select for diffs], Sat Mar 5 20:55:58 2011 UTC (13 years, 1 month ago) by rmind
Branch: rmind-uvmplock
Changes since 1.7.6.1: +701 -0 lines
Diff to previous 1.7.6.1 (colored) to branchpoint 1.7 (colored) next main 1.8 (colored) to selected 1.11.8.7 (colored) 

sync with head

Revision 1.2.4.4 / (download) - annotate - [select for diffs], Sat Nov 6 08:08:50 2010 UTC (13 years, 5 months ago) by uebayasi
Branch: uebayasi-xip
Changes since 1.2.4.3: +86 -42 lines
Diff to previous 1.2.4.3 (colored) to branchpoint 1.2 (colored) next main 1.3 (colored) to selected 1.11.8.7 (colored) 

Sync with HEAD.

Revision 1.7.6.1, Fri Nov 5 00:21:51 2010 UTC (13 years, 5 months ago) by rmind
Branch: rmind-uvmplock
Changes since 1.7: +0 -701 lines
FILE REMOVED 

file ip_reass.c was added on branch rmind-uvmplock on 2011-03-05 20:55:58 +0000

Revision 1.7 / (download) - annotate - [select for diffs], Fri Nov 5 00:21:51 2010 UTC (13 years, 5 months ago) by rmind
Branch: MAIN
CVS Tags: uebayasi-xip-base4, rmind-uvmplock-nbase, rmind-uvmplock-base, matt-mips64-premerge-20101231, jruoho-x86intr-base, jruoho-x86intr, cherry-xenmp-base, cherry-xenmp, bouyer-quota2-nbase, bouyer-quota2-base, bouyer-quota2
Branch point for: rmind-uvmplock
Changes since 1.6: +86 -42 lines
Diff to previous 1.6 (colored) to selected 1.11.8.7 (colored) 

ip_reass_packet: finish abstraction; some clean-up.
Discussed some time ago with matt@.

Revision 1.2.4.3 / (download) - annotate - [select for diffs], Fri Oct 22 07:22:39 2010 UTC (13 years, 6 months ago) by uebayasi
Branch: uebayasi-xip
Changes since 1.2.4.2: +115 -188 lines
Diff to previous 1.2.4.2 (colored) to branchpoint 1.2 (colored) to selected 1.11.8.7 (colored) 

Sync with HEAD (-D20101022).

Revision 1.2.2.3 / (download) - annotate - [select for diffs], Sat Oct 9 03:32:38 2010 UTC (13 years, 6 months ago) by yamt
Branch: yamt-nfs-mp
Changes since 1.2.2.2: +117 -190 lines
Diff to previous 1.2.2.2 (colored) to branchpoint 1.2 (colored) next main 1.3 (colored) to selected 1.11.8.7 (colored) 

sync with head

Revision 1.6 / (download) - annotate - [select for diffs], Thu Oct 7 03:15:49 2010 UTC (13 years, 6 months ago) by yamt
Branch: MAIN
CVS Tags: yamt-nfs-mp-base11, uebayasi-xip-base3
Changes since 1.5: +3 -3 lines
Diff to previous 1.5 (colored) to selected 1.11.8.7 (colored) 

make ipfr_lock IPL_VM as ip_reass_drain is called in interrupts via
the drain hook for mbuf pools.

Revision 1.5 / (download) - annotate - [select for diffs], Wed Oct 6 07:39:37 2010 UTC (13 years, 6 months ago) by enami
Branch: MAIN
Changes since 1.4: +3 -3 lines
Diff to previous 1.4 (colored) to selected 1.11.8.7 (colored) 

Don't free memory still in use.  Fixes nfs root problem reported
by Christoph Egger on source-changes-d.

Revision 1.4 / (download) - annotate - [select for diffs], Sun Oct 3 19:44:47 2010 UTC (13 years, 6 months ago) by rmind
Branch: MAIN
Changes since 1.3: +52 -117 lines
Diff to previous 1.3 (colored) to selected 1.11.8.7 (colored) 

Re-structure IPv4 reassembly code to make it more MP-friendly and simplify
some code fragments while here.  Also, use pool_cache(9) and mutex(9).

IPv4 reassembly mechanism is MP-safe now.

Revision 1.3 / (download) - annotate - [select for diffs], Wed Aug 25 00:05:14 2010 UTC (13 years, 7 months ago) by rmind
Branch: MAIN
Changes since 1.2: +72 -80 lines
Diff to previous 1.2 (colored) to selected 1.11.8.7 (colored) 

Use own IPv4 reassembly queue entry structure and leave struct ipqent only
for TCP.  Now both struct ipfr_qent, struct ipfr_queue and hashed fragment
queue are abstracted and no longer public.

Revision 1.2.4.2 / (download) - annotate - [select for diffs], Tue Aug 17 06:47:46 2010 UTC (13 years, 8 months ago) by uebayasi
Branch: uebayasi-xip
Changes since 1.2.4.1: +730 -0 lines
Diff to previous 1.2.4.1 (colored) to branchpoint 1.2 (colored) to selected 1.11.8.7 (colored) 

Sync with HEAD.

Revision 1.2.2.2 / (download) - annotate - [select for diffs], Wed Aug 11 22:54:56 2010 UTC (13 years, 8 months ago) by yamt
Branch: yamt-nfs-mp
Changes since 1.2.2.1: +730 -0 lines
Diff to previous 1.2.2.1 (colored) to branchpoint 1.2 (colored) to selected 1.11.8.7 (colored) 

sync with head.

Revision 1.2.4.1, Mon Jul 19 14:09:45 2010 UTC (13 years, 9 months ago) by uebayasi
Branch: uebayasi-xip
Changes since 1.2: +0 -730 lines
FILE REMOVED 

file ip_reass.c was added on branch uebayasi-xip on 2010-08-17 06:47:46 +0000

Revision 1.2.2.1, Mon Jul 19 14:09:45 2010 UTC (13 years, 9 months ago) by yamt
Branch: yamt-nfs-mp
Changes since 1.2: +0 -730 lines
FILE REMOVED 

file ip_reass.c was added on branch yamt-nfs-mp on 2010-08-11 22:54:56 +0000

Revision 1.2 / (download) - annotate - [select for diffs], Mon Jul 19 14:09:45 2010 UTC (13 years, 9 months ago) by rmind
Branch: MAIN
CVS Tags: yamt-nfs-mp-base10, uebayasi-xip-base2
Branch point for: yamt-nfs-mp, uebayasi-xip
Changes since 1.1: +83 -30 lines
Diff to previous 1.1 (colored) to selected 1.11.8.7 (colored) 

Abstract IP reassembly into single generic routine - ip_reass_packet().
Make struct ipq private and struct ipqent not visible to userland.
Push ip_len adjustment into reassembly layer.

OK matt@

Revision 1.1 / (download) - annotate - [select for diffs], Tue Jul 13 22:16:10 2010 UTC (13 years, 9 months ago) by rmind
Branch: MAIN
Diff to selected 1.11.8.7 (colored) 

Split-off IPv4 re-assembly mechanism into a separate module.  Abstract
into ip_reass_init(), ip_reass_lookup(), etc (note: abstraction is not
yet complete).  No functional changes to the actual mechanism.

OK matt@

This form allows you to request diff's between any two revisions of a file. You may select a symbolic revision name using the selection box or you may type in a numeric name using the type-in text box.


CVSweb <webmaster@jp.NetBSD.org>