Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
---|---|---|---|---|---|---|
ovs-ctl-ipsec.patch | Don't monitor ipsec daemon For Ubuntu systemd will monitor the ovs-monitor-ipsec daemon so there is no need to spawn a separate monitor thread to deal with restarts. Doing so has the side effect of confusing systemd into monitoring the wrong process. =================================================================== |
James Page <james.page@ubuntu.com> | not-needed | |||
CVE-2023-1668_ofproto-dpif-xlate_Always_mask_ip_proto_field.patch | CVE-2023-1668: ofproto-dpif-xlate: Always mask ip proto field. The ofproto layer currently treats nw_proto field as overloaded to mean both that a proper nw layer exists, as well as the value contained in the header for the nw proto. However, this is incorrect behavior as relevant standards permit that any value, including '0' should be treated as a valid value. . Because of this overload, when the ofproto layer builds action list for a packet with nw_proto of 0, it won't build the complete action list that we expect to be built for the packet. That will cause a bad behavior where all packets passing the datapath will fall into an incomplete action set. . The fix here is to unwildcard nw_proto, allowing us to preserve setting actions for protocols which we know have support for the actions we program. This means that a traffic which contains nw_proto == 0 cannot cause connectivity breakage with other traffic on the link. diff --git a/include/openvswitch/meta-flow.h b/include/openvswitch/meta-flow.h index 045dce8f5fa..3b0220aaa25 100644 |
Aaron Conole <aconole@redhat.com> | no | debian | upstream, https://github.com/openvswitch/ovs/commit/61b39d8c4797f1b668e4d5e5350d639fca6082a9.patch | 2023-04-11 |
CVE-2023-5366-Fix-missing-masks-on-a-final-stage-with-ports-trie.patch | [PATCH] classifier: Fix missing masks on a final stage with ports trie. Flow lookup doesn't include masks of the final stage in a resulting flow wildcards in case that stage had L4 ports match. Only the result of ports trie lookup is added to the mask. It might be sufficient in many cases, but it's not correct, because ports trie is not how we decided that the packet didn't match in this subtable. In fact, we used a full subtable mask in order to determine that, so all the subtable mask bits has to be added. Ports trie can still be used to adjust ports' mask, but it is not sufficient to determine that the packet didn't match. Assuming we have following 2 OpenFlow rules on the bridge: table=0, priority=10,tcp,tp_dst=80,tcp_flags=+psh actions=drop table=0, priority=0 actions=output(1) The first high priority rule supposed to drop all the TCP data traffic sent on port 80. The handshake, however, is allowed for forwarding. Both 'tcp_flags' and 'tp_dst' are on the final stage in the flow. Since the stage mask from that stage is not incorporated into the flow wildcards and only ports mask is getting updated, we have the following megaflow for the SYN packet that has no match on 'tcp_flags': $ ovs-appctl ofproto/trace br0 "in_port=br0,tcp,tp_dst=80,tcp_flags=syn" Megaflow: recirc_id=0,eth,tcp,in_port=LOCAL,nw_frag=no,tp_dst=80 Datapath actions: 1 If this flow is getting installed into datapath flow table, all the packets for port 80, regardless of TCP flags, will be forwarded. Incorporating all the looked at bits from the final stage into the stages map in order to get all the necessary wildcards. Ports mask has to be updated as a last step, because it doesn't cover the full 64-bit slot in the flowmap. With this change, in the example above, OVS is producing correct flow wildcards including match on TCP flags: Megaflow: recirc_id=0,eth,tcp,in_port=LOCAL,nw_frag=no,tp_dst=80,tcp_flags=-psh Datapath actions: 1 This way only -psh packets will be forwarded, as expected. This issue affects all other fields on stage 4, not only TCP flags. Tests included to cover tcp_flags, nd_target and ct_tp_src/dst. First two are frequently used, ct ones are sharing the same flowmap slot with L4 ports, so important to test. Before the pre-computation of stage masks, flow wildcards were updated during lookup, so there was no issue. The bits of the final stage was lost with introduction of 'stages_map'. Recent adjustment of segment boundaries exposed 'tcp_flags' to the issue. |
Ilya Maximets <i.maximets@ovn.org> | no | 2023-02-17 | ||
CVE-2023-3966-netdev-offload-tc_Check_geneve_metadata_length.patch | CVE-2023-3966 netdev-offload-tc: Check geneve metadata length. Currently ovs-vswitchd crashes, with hw offloading enabled, if a geneve packet with corrupted metadata is received, because the metadata header is not verified correctly. . This commit adds a check for geneve metadata length and, if the header is wrong, the packet is not sent to flower. . It also includes a system-traffic test for geneve packets with corrupted metadata. . =================================================================== |
Timothy Redaelli <tredaelli@redhat.com> | no | debian | upstream, https://github.com/openvswitch/ovs/commit/91e621bd5abab19954bec09c7d27c59acdf607b1.patch | 2024-02-18 |