Page MenuHomeFreeBSD

ipv6: account for jumbo payload option
AcceptedPublic

Authored by tuexen on Mon, Dec 29, 1:53 PM.
Tags
None
Referenced Files
F141806329: D54394.diff
Sat, Jan 10, 4:35 PM
Unknown Object (File)
Thu, Jan 8, 12:10 AM
Unknown Object (File)
Tue, Jan 6, 6:51 AM
Unknown Object (File)
Mon, Jan 5, 2:38 PM
Unknown Object (File)
Mon, Jan 5, 2:38 PM

Details

Summary

If a jumbo payload option is added, the length of the mbuf chain is increased by 8 but the actual hop-by-hop extension header with the jumbo playload option is only inserted in the packet if there are other options. Therefore, adjust optlen to reflect the actual size of IPv6 extension headers including the hop-by-hop extension header containing the jumbo payload option.

Reported-by: syzbot+73fe316271df473230eb@syzkaller.appspotmail.com

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

tuexen retitled this revision from ipv6: account for jumbo option to ipv6: account for jumbo payload option.Mon, Dec 29, 2:43 PM
tuexen edited the summary of this revision. (Show Details)
sys/netinet6/ip6_output.c
559

I don't really understand this. We already added optlen to m->m_pkthdr.len above. Why don't we need to do that for a lone jumbo header?

sys/netinet6/ip6_output.c
559

Because if optlen is zero, we don't put the actual header in place. The hop-by-hop extension header is put in place in line ip6_output.c#n601, which is protected by optlen > 0 in ip6_output.c#n563.
A correct value of optlen is also crucial for the checksum computation in ip6_output.c:1141. This is where syzcaller was triggering a panic.

sys/netinet6/ip6_output.c
559

Because if optlen is zero, we don't put the actual header in place. The hop-by-hop extension header is put in place in line ip6_output.c#n601, which is protected by optlen > 0 in ip6_output.c#n563.

I understand, I'm asking about the code on line 542.

sys/netinet6/ip6_output.c
559

Because optlen does not include the jumbo payload option at the time of the increment of m_pkthdr.len. The 8 bytes are added later to m_pkthdr.len in ip6_insert_jumboopt() in line 1396. This means without this patch, optlen never includes the jumbo payload option, but m_pkthdr.len does, if the jumbo payload option should be included. However, it is only included, if optlen is positive. This results in the situation, where m_pkthdr.len indicates 8 more bytes than they are actually in the mbuf chain, since the hop-by-hop option was never inserted.

I agree @markj. It is not easy to understand the code. However, before this patch, without any other options, optlen is 0 and, thus, the jumbo option will never be added.

This patch fixes the bug. Making the code more readable might make sense, but I would separate that from this patch.

This revision is now accepted and ready to land.Fri, Jan 2, 9:36 AM

I suspect we should move the optlen value into struct ip6_exthdrs, and update it directly in ip6_insert_jumboopt().