CVE-2024-38558

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: openvswitch: fix overwriting ct original tuple for ICMPv6<br /> <br /> OVS_PACKET_CMD_EXECUTE has 3 main attributes:<br /> - OVS_PACKET_ATTR_KEY - Packet metadata in a netlink format.<br /> - OVS_PACKET_ATTR_PACKET - Binary packet content.<br /> - OVS_PACKET_ATTR_ACTIONS - Actions to execute on the packet.<br /> <br /> OVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key structure<br /> with the metadata like conntrack state, input port, recirculation id,<br /> etc. Then the packet itself gets parsed to populate the rest of the<br /> keys from the packet headers.<br /> <br /> Whenever the packet parsing code starts parsing the ICMPv6 header, it<br /> first zeroes out fields in the key corresponding to Neighbor Discovery<br /> information even if it is not an ND packet.<br /> <br /> It is an &amp;#39;ipv6.nd&amp;#39; field. However, the &amp;#39;ipv6&amp;#39; is a union that shares<br /> the space between &amp;#39;nd&amp;#39; and &amp;#39;ct_orig&amp;#39; that holds the original tuple<br /> conntrack metadata parsed from the OVS_PACKET_ATTR_KEY.<br /> <br /> ND packets should not normally have conntrack state, so it&amp;#39;s fine to<br /> share the space, but normal ICMPv6 Echo packets or maybe other types of<br /> ICMPv6 can have the state attached and it should not be overwritten.<br /> <br /> The issue results in all but the last 4 bytes of the destination<br /> address being wiped from the original conntrack tuple leading to<br /> incorrect packet matching and potentially executing wrong actions<br /> in case this packet recirculates within the datapath or goes back<br /> to userspace.<br /> <br /> ND fields should not be accessed in non-ND packets, so not clearing<br /> them should be fine. Executing memset() only for actual ND packets to<br /> avoid the issue.<br /> <br /> Initializing the whole thing before parsing is needed because ND packet<br /> may not contain all the options.<br /> <br /> The issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn&amp;#39;t<br /> affect packets entering OVS datapath from network interfaces, because<br /> in this case CT metadata is populated from skb after the packet is<br /> already parsed.