Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp2282711pxp; Mon, 21 Mar 2022 15:49:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJysnIbpjoS5EANg2MQSnBZhQrvyy37u++s7GK42Zs1KY3yM8CGTJXrX8HFeLVM42sms6Gbq X-Received: by 2002:a17:902:b7cb:b0:154:57eb:c754 with SMTP id v11-20020a170902b7cb00b0015457ebc754mr7240209plz.2.1647902987818; Mon, 21 Mar 2022 15:49:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1647902987; cv=none; d=google.com; s=arc-20160816; b=HjNytEdz8OULM+Hwavmt3fcLXVAjW+FiWOVm09VpofxCS+YgWoaxkH4njC8z+P4kVp MwmLjddej1UD9uisCiWZKEfg+2kKCb0R6CjmAs9yS+fZZUPBpgiEbD6v7AGRNdrI5fja Si1SaXS/190XaQdM84Q0DNfCCNJvs54mtjC0yo21ekF0zu7qkR7/DzsvyOCmH8U9hj65 5kvI5w63/wJhZaHNwCqKC7zN+OH9nMl6x/TbJ+yngu//kpqM2yz9PU/elkQN56S3/TNR 8Sp2T0ldEz7KEvrYSBecJQ0ARHm4av2wDqrmvJ2a1T9cku8LAJASJGjtoadj+L8UJ1xB T5HQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=oijpL0AmcHr6en0Bi9+avHMS7JPMoPv3d4jrY2xiU3o=; b=uFUKmDvm6vFJ9vLjCQdu15huO/YMPTW3wZoO+vMitieVZebIzhUVCF7QuA83Hyj2K9 rsDvrxy0DNcHLqy9fCPybp3FhhMOxjbwDRstJKrvhmpkQrGh6ODQuBBmGsqTQq9mgU0K ESpUHhxyLKNZFIWBuB2nSuAseHT9ASeVWbO5U20dN9TAYbS1yns3OAgA2O1wc8jfYFtE rjOWfTyFTjMtVEit/mlqnXswWFOv/i22EvnLQFwLRDTDIqfDTYgrqsgrEBOb/ZG6A60z fUth2t+jg6fgZlp95IlP6HQWZA9oE0va+nfoSp0OnFnk+hgHFro/2N47jNM7X9xMZ7q3 VwOQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="CiH/1Ha3"; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id m11-20020a638c0b000000b003816043f022si14246401pgd.535.2022.03.21.15.49.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Mar 2022 15:49:47 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="CiH/1Ha3"; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id E6C0D3F584D; Mon, 21 Mar 2022 14:57:39 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1351857AbiCUOMB (ORCPT + 99 others); Mon, 21 Mar 2022 10:12:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35098 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348944AbiCUOFK (ORCPT ); Mon, 21 Mar 2022 10:05:10 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4AF01181B2C; Mon, 21 Mar 2022 07:01:29 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id ECD4BB816CE; Mon, 21 Mar 2022 14:01:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 444E9C340ED; Mon, 21 Mar 2022 14:01:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1647871284; bh=2nO093whqQ/sqbYqWbv0LaogH00/S1O/HY0QpO+NfNU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CiH/1Ha3UbvdZ/nBRLVJd6kUz7aGcQhQHHO4sa86nQubwWOQzW7oodf667KRnFCKV K8RokQAh33z3sinIIsyqf9akd+P2m6/zx/PvNpupsqFaMhl8XEpeWY4opG5fyyMfOd YKdnWim2sof2Fu26ow7wqzoW8IfaSpJH/AaT63Lc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Xiumei Mu , Sabrina Dubroca , Steffen Klassert , Sasha Levin Subject: [PATCH 5.15 09/32] esp6: fix check on ipv6_skip_exthdrs return value Date: Mon, 21 Mar 2022 14:52:45 +0100 Message-Id: <20220321133220.833086671@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220321133220.559554263@linuxfoundation.org> References: <20220321133220.559554263@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Sabrina Dubroca [ Upstream commit 4db4075f92af2b28f415fc979ab626e6b37d67b6 ] Commit 5f9c55c8066b ("ipv6: check return value of ipv6_skip_exthdr") introduced an incorrect check, which leads to all ESP packets over either TCPv6 or UDPv6 encapsulation being dropped. In this particular case, offset is negative, since skb->data points to the ESP header in the following chain of headers, while skb->network_header points to the IPv6 header: IPv6 | ext | ... | ext | UDP | ESP | ... That doesn't seem to be a problem, especially considering that if we reach esp6_input_done2, we're guaranteed to have a full set of headers available (otherwise the packet would have been dropped earlier in the stack). However, it means that the return value will (intentionally) be negative. We can make the test more specific, as the expected return value of ipv6_skip_exthdr will be the (negated) size of either a UDP header, or a TCP header with possible options. In the future, we should probably either make ipv6_skip_exthdr explicitly accept negative offsets (and adjust its return value for error cases), or make ipv6_skip_exthdr only take non-negative offsets (and audit all callers). Fixes: 5f9c55c8066b ("ipv6: check return value of ipv6_skip_exthdr") Reported-by: Xiumei Mu Signed-off-by: Sabrina Dubroca Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin --- net/ipv6/esp6.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/net/ipv6/esp6.c b/net/ipv6/esp6.c index b7b573085bd5..5023f59a5b96 100644 --- a/net/ipv6/esp6.c +++ b/net/ipv6/esp6.c @@ -813,8 +813,7 @@ int esp6_input_done2(struct sk_buff *skb, int err) struct tcphdr *th; offset = ipv6_skip_exthdr(skb, offset, &nexthdr, &frag_off); - - if (offset < 0) { + if (offset == -1) { err = -EINVAL; goto out; } -- 2.34.1