Now
netbsd-8 commitmail json YAML
Pull up following revision(s) (requested by maxv in ticket #893):
sys/netinet6/icmp6.c: revision 1.228,1.230
Remove the RH0 code from ICMPv6. RH0 is deprecated by RFC5095 (2007) for
security reasons. We already removed it in Route6.
In addition there was an mbuf bug here: calling IP6_EXTHDR_GET twice with
the same offset, but still using the pointer from the first call, which
could have been made invalid. By luck, m_pulldown leaves zero-sized mbufs
in place, instead of freeing them.
And in general, using a 'finaldst' pointer on the mbuf, and then modifying
that mbuf with IP6_EXTHDR_GET with a smaller offset, was really error-
prone.
Fix 'icmp6len', it shouldn't be ip6_plen, because we may not be at the
beginning of the packet (off+ip6_plen is beyond the end of the mbuf). By
luck, the IP6_EXTHDR_GET that follows will fail and prevent buffer
overflows in non-jumbogram packets.
For jumbograms we will probably be in trouble here; but it doesn't seem
possible to craft reliably a jumbogram for a non-jumbogram-enabled device.
So I don't think it's a huge problem.
sys/netinet6/icmp6.c: revision 1.228,1.230
Remove the RH0 code from ICMPv6. RH0 is deprecated by RFC5095 (2007) for
security reasons. We already removed it in Route6.
In addition there was an mbuf bug here: calling IP6_EXTHDR_GET twice with
the same offset, but still using the pointer from the first call, which
could have been made invalid. By luck, m_pulldown leaves zero-sized mbufs
in place, instead of freeing them.
And in general, using a 'finaldst' pointer on the mbuf, and then modifying
that mbuf with IP6_EXTHDR_GET with a smaller offset, was really error-
prone.
Fix 'icmp6len', it shouldn't be ip6_plen, because we may not be at the
beginning of the packet (off+ip6_plen is beyond the end of the mbuf). By
luck, the IP6_EXTHDR_GET that follows will fail and prevent buffer
overflows in non-jumbogram packets.
For jumbograms we will probably be in trouble here; but it doesn't seem
possible to craft reliably a jumbogram for a non-jumbogram-enabled device.
So I don't think it's a huge problem.