From nobody Mon Apr 20 07:30:15 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DEF9DC433EF for ; Tue, 21 Jun 2022 20:55:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1354981AbiFUUzL (ORCPT ); Tue, 21 Jun 2022 16:55:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44520 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1354606AbiFUUvi (ORCPT ); Tue, 21 Jun 2022 16:51:38 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 3BEE12FE4F for ; Tue, 21 Jun 2022 13:48:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1655844537; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=1ZiU/FWNuW0DHUEQT+r8cgWumVWHOL8vQv6l7HeOPfE=; b=iXe1uTKoY35NFAgPQOM5nlT/etiae1aN2qZrmjxO23vq//0977h+oq6UPDkXtmppfx+6SC aZHjSShA99h3yxvE6KU2ooeG6SDQKd2W1NYfK6/M7n5o+JXtINBWpbUvdgwO6Z8+K8tihx n/MM5XF4cpDFsCMj+qeG+Z2X+lE6/4o= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-488-XJPZIo6ZPpiTmRO4u21yww-1; Tue, 21 Jun 2022 16:48:54 -0400 X-MC-Unique: XJPZIo6ZPpiTmRO4u21yww-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 3168D80A0AD; Tue, 21 Jun 2022 20:48:53 +0000 (UTC) Received: from localhost.localdomain (unknown [10.22.12.1]) by smtp.corp.redhat.com (Postfix) with ESMTP id A15F640CF8E2; Tue, 21 Jun 2022 20:48:52 +0000 (UTC) From: Rosemarie O'Riorden To: netdev@vger.kernel.org Cc: Pravin B Shelar , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Yi-Hung Wei , dev@openvswitch.org, linux-kernel@vger.kernel.org, i.maximets@ovn.org, aconole@redhat.com Subject: [PATCH net] net: openvswitch: fix parsing of nw_proto for IPv6 fragments Date: Tue, 21 Jun 2022 16:48:45 -0400 Message-Id: <20220621204845.9721-1-roriorden@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.84 on 10.11.54.1 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" When a packet enters the OVS datapath and does not match any existing flows installed in the kernel flow cache, the packet will be sent to userspace to be parsed, and a new flow will be created. The kernel and OVS rely on each other to parse packet fields in the same way so that packets will be handled properly. As per the design document linked below, OVS expects all later IPv6 fragments to have nw_proto=3D44 in the flow key, so they can be correctly matched on OpenFlow rules. OpenFlow controllers create pipelines based on this design. This behavior was changed by the commit in the Fixes tag so that nw_proto equals the next_header field of the last extension header. However, there is no counterpart for this change in OVS userspace, meaning that this field is parsed differently between OVS and the kernel. This is a problem because OVS creates actions based on what is parsed in userspace, but the kernel-provided flow key is used as a match criteria, as described in Documentation/networking/openvswitch.rst. This leads to issues such as packets incorrectly matching on a flow and thus the wrong list of actions being applied to the packet. Such changes in packet parsing cannot be implemented without breaking the userspace. The offending commit is partially reverted to restore the expected behavior. The change technically made sense and there is a good reason that it was implemented, but it does not comply with the original design of OVS. If in the future someone wants to implement such a change, then it must be user-configurable and disabled by default to preserve backwards compatibility with existing OVS versions. Cc: stable@vger.kernel.org Fixes: fa642f08839b ("openvswitch: Derive IP protocol number for IPv6 later= frags") Link: https://docs.openvswitch.org/en/latest/topics/design/#fragments Signed-off-by: Rosemarie O'Riorden Acked-by: Eelco Chaudron --- net/openvswitch/flow.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c index 372bf54a0ca9..e20d1a973417 100644 --- a/net/openvswitch/flow.c +++ b/net/openvswitch/flow.c @@ -407,7 +407,7 @@ static int parse_ipv6hdr(struct sk_buff *skb, struct sw= _flow_key *key) if (flags & IP6_FH_F_FRAG) { if (frag_off) { key->ip.frag =3D OVS_FRAG_TYPE_LATER; - key->ip.proto =3D nexthdr; + key->ip.proto =3D NEXTHDR_FRAGMENT; return 0; } key->ip.frag =3D OVS_FRAG_TYPE_FIRST; --=20 2.35.3