Makefile.am | 1 0 + 1 - 0 !
1 file changed, 1 deletion(-)

 remove debian/automake.mk

python/ovstest/rpcserver.py | 16 5 + 11 - 0 !
python/ovstest/tcp.py | 4 2 + 2 - 0 !
python/ovstest/util.py | 4 1 + 3 - 0 !
python/ovstest/vswitch.py | 5 4 + 1 - 0 !
utilities/ovs-check-dead-ifs.in | 2 2 + 0 - 0 !
utilities/ovs-dpctl-top.in | 2 2 + 0 - 0 !
utilities/ovs-l3ping.in | 12 7 + 5 - 0 !
utilities/ovs-parse-backtrace.in | 14 8 + 6 - 0 !
utilities/ovs-tcpdump.in | 2 2 + 0 - 0 !
utilities/ovs-tcpundump.in | 2 2 + 0 - 0 !
utilities/ovs-test.in | 39 21 + 18 - 0 !
utilities/ovs-vlan-test.in | 25 14 + 11 - 0 !
12 files changed, 70 insertions(+), 57 deletions(-)

 [patch] python 3 support

Misc fixes to Python based tooling for compatibility with
Python 2 and 3.

Signed-off-by: James Page <james.page@ubuntu.com>

lib/ofp-actions.c | 2 2 + 0 - 0 !
tests/automake.mk | 3 2 + 1 - 0 !
tests/fuzz-regression-list.at | 1 1 + 0 - 0 !
3 files changed, 5 insertions(+), 1 deletion(-)

 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.

lib/lldp/lldp.c | 2 2 + 0 - 0 !
1 file changed, 2 insertions(+)

 cve-2022-4337 cve-2022-4338 fix bugs when parsing malformed lldp packets

tests/system-traffic.at | 31 31 + 0 - 0 !
1 file changed, 31 insertions(+)

 cve-2022-4337 cve-2022-4338 add a unit test for lldp

lib/ovsdb-idl.c | 12 9 + 3 - 0 !
1 file changed, 9 insertions(+), 3 deletions(-)

 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>

include/openvswitch/meta-flow.h | 4 4 + 0 - 0 !
lib/meta-flow.c | 25 25 + 0 - 0 !
ofproto/ofproto-dpif-xlate.c | 8 8 + 0 - 0 !
tests/ofproto-dpif.at | 18 9 + 9 - 0 !
tests/ofproto.at | 182 182 + 0 - 0 !
tests/packet-type-aware.at | 2 1 + 1 - 0 !
6 files changed, 229 insertions(+), 10 deletions(-)

 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.
Reported-by: David Marchand <dmarchand@redhat.com>
Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2134873

lib/classifier.c | 25 20 + 5 - 0 !
tests/classifier.at | 88 88 + 0 - 0 !
2 files changed, 108 insertions(+), 5 deletions(-)

 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

lib/netdev-offload-tc.c | 33 23 + 10 - 0 !
lib/tc.c | 13 10 + 3 - 0 !
2 files changed, 33 insertions(+), 13 deletions(-)

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

Fixes: a468645c6d33 ("lib/tc: add geneve with option match offload")

lib/netdev-offload-tc.c | 86 75 + 11 - 0 !
tests/system-offloads-traffic.at | 33 33 + 0 - 0 !
2 files changed, 108 insertions(+), 11 deletions(-)

 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.
 .
Fixes: a468645c6d33 ("lib/tc: add geneve with option match offload")
Reported-by: Haresh Khandelwal <hakhande@redhat.com>
Signed-off-by: Timothy Redaelli <tredaelli@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Bug-Debian: https://bugs.debian.org/1063492

lib/pcap-file.c | 1 1 + 0 - 0 !
1 file changed, 1 insertion(+)

 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

include/openvswitch/flow.h | 4 2 + 2 - 0 !
tests/classifier.at | 25 25 + 0 - 0 !
2 files changed, 27 insertions(+), 2 deletions(-)

 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)

ofproto/ofproto-dpif-xlate.c | 21 21 + 0 - 0 !
1 file changed, 21 insertions(+)

 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