Change Details

There's a concurrency issue in setups with if_bridge, if_epair and a real interface. The setup is: re0 -- real interface epair0 -- epair, with one side A in jail 0, side B in jail 1 bridge0 -- bridge with addm re0 addm epair0a If you send a broadcast udp packet through re0 (with a UDP checksum), there's a chance that it will be sent on the network with a bad checksum, and that checksum will be the UDP size. This seems to be happening as a result of the following chain: a) if_bridge.c:bridge_output uses m_copypacket to generate an mbuf with shared data, which is then enqueued to each interface in the bridge (with the add order above, epair0a goes first) b) if_epair sends the mbuf to side B c) udp_usrreq.c:udp_input (in the vtnet jail, processing the incoming packet on epair0b) munges the data in the mbuf as part of verifying the checksum; it puts most of the data back, but the IP header checksum value is replaced with the UDP length. d) if_re sends the packet out on the physical interface Unshare the mbuf prior to enqueuing it to ensure that any modifications the receiving epair makes don't affect other interfaces. MFC after: 3 weeks

if_bridge duplicates broadcast packets with m_copypacket(), which creates shared packets. In certain circumstances these packets can be processed by udp_usrreq.c:udp_input() first, which modifies the mbuf as part of the cecksum verification. That may lead to incorrect packets being transmitted. Use m_dup() to create independent mbufs instead. Reported by: Richard Russo <toast@ruka.org> MFC after: 2 weeks

There's a concurrency issue in setupif_bridge duplicates broadcast packets with if_bridgem_copypacket(), if_epair and awhich real interface. The setup is: re0 -- real interfacecreates shared packets. In certain circumstances these packets can be epair0 -- epair, with one side A in jail 0processed by udp_usrreq.c:udp_input() first, side B in jail 1which modifies the mbuf as bridge0 -- bridge with addm re0 addm epair0a If you send a broadcast udp packet through re0 (with a UDP checksum),part of the cecksum verification. That may lead to incorrect packets there's a chance that it will be sent on the network with a bad checksum, and that checksum will be the UDP sizebeing transmitted. This seemsUse m_dup() to be happening as a result of the following chain:create independent mbufs instead. a) if_bridge.c:bridge_output uses m_copypacket to generate an mbuf withReported by: Richard Russo <toast@ruka.org> shared data, which is then enqueued to each interface in the bridge (with the add order above, epair0a goes first) b) if_epair sends the mbuf to side B c) udp_usrreq.c:udp_input (in the vtnet jail, processing the incoming packet on epair0b) munges the data in the mbuf as part of verifying the checksum; it puts most of the data back, but the IP header checksum value is replaced with the UDP length. d) if_re sends the packet out on the physical interface Unshare the mbuf prior to enqueuing it to ensure that any modifications the receiving epair makes don't affect other interfaces. MFC after: 3MFC after: 2 weeks