| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| remove-include-debian-automake.mk.patch | Remove debian/automake.mk =================================================================== |
Thomas Goirand <zigo@debian.org> | not-needed | 2017-10-20 | ||
| py3-compat.patch | [PATCH] Python 3 support Misc fixes to Python based tooling for compatibility with Python 2 and 3. |
James Page <james.page@ubuntu.com> | no | 2018-02-08 | ||
| CVE-2021-36980_Fix_use-after-free_while_decoding_RAW_ENCAP.patch | CVE-2021-36980: ofp-actions: Fix use-after-free while decoding RAW_ENCAP. While decoding RAW_ENCAP action, decode_ed_prop() might re-allocate ofpbuf if there is no enough space left. However, function 'decode_NXAST_RAW_ENCAP' continues to use old pointer to 'encap' structure leading to write-after-free and incorrect decoding. . ==3549105==ERROR: AddressSanitizer: heap-use-after-free on address 0x60600000011a at pc 0x0000005f6cc6 bp 0x7ffc3a2d4410 sp 0x7ffc3a2d4408 WRITE of size 2 at 0x60600000011a thread T0 #0 0x5f6cc5 in decode_NXAST_RAW_ENCAP lib/ofp-actions.c:4461:20 #1 0x5f0551 in ofpact_decode ./lib/ofp-actions.inc2:4777:16 #2 0x5ed17c in ofpacts_decode lib/ofp-actions.c:7752:21 #3 0x5eba9a in ofpacts_pull_openflow_actions__ lib/ofp-actions.c:7791:13 #4 0x5eb9fc in ofpacts_pull_openflow_actions lib/ofp-actions.c:7835:12 #5 0x64bb8b in ofputil_decode_packet_out lib/ofp-packet.c:1113:17 #6 0x65b6f4 in ofp_print_packet_out lib/ofp-print.c:148:13 #7 0x659e3f in ofp_to_string__ lib/ofp-print.c:1029:16 #8 0x659b24 in ofp_to_string lib/ofp-print.c:1244:21 #9 0x65a28c in ofp_print lib/ofp-print.c:1288:28 #10 0x540d11 in ofctl_ofp_parse utilities/ovs-ofctl.c:2814:9 #11 0x564228 in ovs_cmdl_run_command__ lib/command-line.c:247:17 #12 0x56408a in ovs_cmdl_run_command lib/command-line.c:278:5 #13 0x5391ae in main utilities/ovs-ofctl.c:179:9 #14 0x7f6911ce9081 in __libc_start_main (/lib64/libc.so.6+0x27081) #15 0x461fed in _start (utilities/ovs-ofctl+0x461fed) . Fix that by getting a new pointer before using. . Credit to OSS-Fuzz. . Fuzzer regression test will fail only with AddressSanitizer enabled. diff --git a/lib/ofp-actions.c b/lib/ofp-actions.c index e2e829772a5..0342a228b70 100644 |
Ilya Maximets <i.maximets@ovn.org> | no | debian | upstream, https://github.com/openvswitch/ovs/commit/38744b1bcb022c611712527f039722115300f58f.patch | 2021-07-21 |
| CVE-2022-4337and8_1_fix_bugs_when_parsing_malformed_LLDP_packets.patch | CVE-2022-4337 CVE-2022-4338 fix bugs when parsing malformed LLDP packets =================================================================== |
cq <cq674350529@163.com> | no | debian | upstream, https://github.com/openvswitch/ovs/commit/48b21e2b511a4d1ee5871e04fffe26a3ecc967dc.patch | 2023-01-03 |
| CVE-2022-4337and8_2_Add_a_unit_test_for_LLDP.patch | CVE-2022-4337 CVE-2022-4338 Add a unit test for LLDP =================================================================== |
cq <cq674350529@163.com> | no | debian | upstream, https://github.com/openvswitch/ovs/commit/e00600a8892dc9e245222e1de0b12fff186aaeda.patch | 2023-01-03 |
| fix_ovsdb-idl_fix-the-database-update-signaling-if-it-has-never-been-connected.patch | ovsdb-idl: Fix the database update signaling if it has never been connected The symptom of this issue is that OVS bridge looses its IP address on restart. . Simple reproducer: 0. start ovsdb-server and ovs-vswitchd 1. ovs-vsctl add-br br0 2. ifconfig br0 10.0.0.1 up 3. ovs-appctl -t ovs-vswitchd exit 4. start ovs-vswitchd back. . After step #3 ovs-vswitchd is down, but br0 interface exists and has configured IP address. After step #4 there is no IP address on the port br0. . What happened: 1. ovsdb-cs connects to the database via ovsdb-idl and requests database lock. --> get_schema for _Server database --> lock request . 2. ovsdb-cs receives schema for the _Server database. And sends monitor request. <-- schema for _Server --> monitor_cond for _Server . 3. ovsdb-cs receives lock reply. <-- locked At this point ovsdb-cs generates OVSDB_CS_EVENT_TYPE_LOCKED event and passes it to ovsdb-idl. ovsdb-idl increases change_seqno. . 4. ovsdb_idl_has_ever_connected() is 'true' now, because change_seqno is not zero. . 5. ovs-vswitchd decides that it has connection with database and all the initial data, therefore initiates configuration of bridges. bridge_run():ovsdb_idl_has_ever_connected() --> true . 6. Since monitor request for the Open_vSwitch database is not even sent yet, the database is empty. This leads to removal of all the ports and all other resources. . 7. When data finally received, ovs-vswitchd re-creates bridges and ports, but IP addresses can not be restored. . While splitting out ovsdb-cs from ovsdb-idl one part of the logic was lost. Particularly, before the split, ovsdb-idl updated change_seqno only in MONITORING state. . Restoring the logic by updating the change_seqno only if may send transaction, i.e. lock is ours and ovsdb-cs is in the MONITORING state. This matches with the main purpose of increasing change_seqno at this point, i.e. to force the client to re-try the transaction. With this change ovsdb_idl_has_ever_connected() remains 'false' until the first monitor reply with the actual data received. . This issue was reported several times during the last couple of weeks. . Reported-at: https://bugzilla.redhat.com/1968445 Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2021-June/383512.html Reported-at: https://mail.openvswitch.org/pipermail/ovs-discuss/2021-June/051222.html Fixes: 1c337c43ac1c ("ovsdb-idl: Break into two layers.") Signed-off-by: Ilya Maximets <i.maximets@ovn.org> Acked-by: Dumitru Ceara <dceara@redhat.com> Author: Ilya Maximets <i.maximets@ovn.org> Date: Tue, 8 Jun 2021 15:17:23 +0200 |
Ilya Maximets <i.maximets@ovn.org> | no | debian | upstream, https://github.com/openvswitch/ovs/commit/bc0aa785a83c11dab482b3e20736b969174d9f86.patch | 2023-01-26 |
| 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. =================================================================== |
Aaron Conole <aconole@redhat.com> | no | debian | upstream, https://github.com/openvswitch/ovs/commit/f36509fd64e339ffd33593451099be6baa12ffe6.patch | 2023-04-11 |
| CVE-2023-5366-Fix-missing-masks-on-a-final-stage-with-ports-trie.patch | CVE-2023-5366 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. . From a7c572e9a1cda2851b50a744f4e84087ed7bdda3 Mon Sep 17 00:00:00 2001 diff --git a/lib/classifier.c b/lib/classifier.c index c4790ee6b..f6a86b662 100644 |
Ilya Maximets <i.maximets@ovn.org> | no | 2024-02-25 | ||
| CVE-2023-3966-netdev-offload-tc-Fix-the-mask-for-tunnel-metadata-l.patch | [PATCH] netdev-offload-tc: Fix the mask for tunnel metadata length. 'wc.masks.tunnel.metadata.present.len' must be a mask for the same field in the flow key, but in the tc_flower structure it's the real length of metadata masks. That is correctly handled for the individual opt->length, setting all the masks to 0x1f like it's done in the tun_metadata_to_geneve_mask__(), but not handled for the main 'len' field. Fix that by setting the mask to 0xff like it's done during the flow translation in xlate_actions() and during the flow dump in the tun_metadata_from_geneve_nlattr(). Also, flower always has an exact match on the present.len field regardless of its value and regardless of this field being masked by OVS flow translation layer while installing the flow. Hence, all tunnel flows dumped from TC should have an exact match on present.len and also UDPIF flag, because present.len doesn't make sense without that flag. Without the change, zero-length options match is incorrectly reported as a wildcard match. The side effect though is that zero-length match on geneve options is reported even for other tunnel types, e.g. vxlan. But that should be fairly harmless. To avoid reporting a match on empty geneve options for vxlan/etc. tunnels we'll need to check the tunnel port type, there is no enough information in the TUNNEL attribute itself. Extra checks and comments added around the code to better explain what is going on. |
Ilya Maximets <i.maximets@ovn.org> | no | 2022-08-14 | ||
| 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 |
| CVE-2024-22563_Fix-memory-leak-in-ovs_pcap_open.patch | CVE-2024-22563: pcap-file: Fix memory leak in ovs_pcap_open(). In ovs_pcap_open(), we allocate memory for the 'p_file' structure but not released when fopen fails. . Addresses-Coverity: ("Resource leak") From 3168f328c78cf6e4b3022940452673b0e49f7620 Mon Sep 17 00:00:00 2001 diff --git a/lib/pcap-file.c b/lib/pcap-file.c index b30a11c24b8..41835f6f4dd 100644 |
Yunjian Wang <wangyunjian@huawei.com> | no | 2024-02-25 | ||
| adjust-segment-boundary.patch | Adjust segment boundary to execute prerequisite processing. The fix for the CVE-2023-5666 depends on the changeset in this patch, otherwise the information tp_dst will not be exposed in the trace, failing the testsuite introduced with CVE-2023-5366.patch. (The patch has been determinded using git bisect) =================================================================== |
no | https://github.com/openvswitch/ovs/commit/ca44218515f02d7421e4b228e0a3b6ee2cefffcf | |||
| fix-testcase-ipv6-ND-dependency.patch | Fix "testcase ipv6 ND dependency" ofproto: Fix for frequent invalidation of mega flows for push actions . When a packet is processed by the slow path and the matching OpenFlow rule has actions like push_mpls/set_field and push_vlan/set_field, the ofproto layer un-wildcards the MPLS and VLAN match fields in the megaflow entry that it plans to install. However, when the megaflow entry is actually installed, all protocol match fields that are not present in the packet are wildcarded. Thus, the wildcard bits in the installed megaflow entry could be different from the bits originally generated by the ofproto layer. . When the revalidator thread validates a megaflow, it will first query the ofproto layer to get the wildcard bits and then compare it against the wildcard bits in the megaflow. If the bits are different the entry will be removed. A subsequent packet will again result in the same megaflow entry being installed only for it to be removed by the revalidator thread. This cycle will continue and will significantly degrade performance. . This patch fixes the issue by wildcarding flow fields which are not present in the incoming packet. . (This failed the testcase introduced with Adjust-segment-boundary.patch with the name ipv6 ND dependency. The patch has been found using git bisect.) =================================================================== |
no |