| 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 |