CVE-2023-3966 (https://mail.openvswitch.org/pipermail/ovs-announce/2024-February/000339.html): "Multiple versions of Open vSwitch are vulnerable to crafted Geneve packets causing invalid memory accesses and potential denial of service. Triggering the vulnerability requires that Open vSwitch has flow hardware offload with Linux TC flower enabled (other_config:hw-offload=true). It is not enabled by default. The issue is caused by insufficient validation of Geneve metadata fields in the offload path. Open vSwitch versions 2.12 and newer are affected." CVE-2023-5366 (https://mail.openvswitch.org/pipermail/ovs-announce/2024-February/000340.html): " In multiple versions of Open vSwitch, if OpenFlow rules on a switch contain a match on a Target Address (nd_target) of Neighbor Discovery IPv6 packets (Neighbor Solicitation or Neighbor Advertisement) without also matching on ICMPv6 Code (icmp_code or icmpv6_code) field being zero, the match on the Target Address can be ignored and the specified actions may be executed for a packet with a different Target Address. This constitutes vulnerability if such OpenFlow rules are used in order to provide Neighbor Discovery anti-spoofing protection. For example, the following set of rules may allow packets with any nd_target, even though it should only allow packets with the 2001::1 Target: priority=10 icmp6,icmpv6_type=136,nd_target=2001::1 actions=<allow> priority=0 icmp6 actions=drop The issue is caused by the difference between the OpenFlow specification that only lists ICMPV6 TYPE=135 or ICMPV6 TYPE=136 as a prerequisite for the IPV6_ND_TARGET and datapath implementations that treat ICMPV6_CODE=0 as a requirement for a packet to have the Target Address option. This leads to creation of an overly broad datapath flow that matches packets regardless of the Target Address value. Triggering the issue depends on the order in which packets are seen by the switch. Open vSwitch versions 2.1 and newer are affected." Fixes are in 2.17.9 according to URL.
Looks like the maintainer didn't touch this for a year. dev-python/ovs (which seems to be supposed to be bumped in sync) is even worse.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=56862b6d530936efea7f6305dc100936ff95ddf6 commit 56862b6d530936efea7f6305dc100936ff95ddf6 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2024-05-05 15:36:37 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2024-05-05 15:53:56 +0000 package.mask: Last rite dev-python/ovs, net-misc/openvswitch Bug: https://bugs.gentoo.org/924129 Signed-off-by: Michał Górny <mgorny@gentoo.org> profiles/package.mask | 7 +++++++ 1 file changed, 7 insertions(+)
I've updated both openvswitch and ovs to the latest lts versions.
(In reply to Michał Górny from comment #1) > Looks like the maintainer didn't touch this for a year. dev-python/ovs > (which seems to be supposed to be bumped in sync) is even worse. mgorny: How do you get a year here? The virtualization project maintains the package, and juippis as one of the project members merged prior PRs, and stabilized the 2.17.8 release on 2024-04-29. That was 5 days before your last-rites. For net-misc/openvswitch: 2.17.x are the LTS series. 2.17.8 wasn't a security fix, and was released upstream 2023--10-17; added to Gentoo 2024/02/09. 2.17.9 was the security fix, released upstream 2024-02-08 For dev-python/ovs, the Python bindings: Same 2.17.x LTS series that need to match the openvswitch release. Upstream does have release gaps, and one minor bump was missed, but at a glance it mostly ripped out the Python2 support. Upstream releases for the bindings: 2.17.1.post1 2.17.7 2.17.9
Re-opening and updating whiteboard status since this package is no longer masked. Next up is a stable bug for the fixed version 2.17.9-r1.
