Received: by 10.223.185.116 with SMTP id b49csp6397100wrg; Wed, 28 Feb 2018 08:44:16 -0800 (PST) X-Google-Smtp-Source: AH8x227GHrJ+dRE5fOyg6XzSoRZzB7HSGAwMeodH3Sop7wfBLTmX0YBLikLDqvQtU6N9ZB6sonc3 X-Received: by 10.101.88.15 with SMTP id g15mr14537489pgr.383.1519836256811; Wed, 28 Feb 2018 08:44:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519836256; cv=none; d=google.com; s=arc-20160816; b=pZIhJctRSJ2LfZNPve74yQF4uH6TRE0hnTm+Sn09OFKyfLGysBSF5C/y5AxZXI0ax1 QLzrMI5QPAICS4XDBT3gIScmH755WuwYkvihxBsma8DLI7q2KFJdqLhq+2gD7jLHKjvh bnke1NxH3dLIodtD1FrHJDrFlxSRXNaXVyvuzR/xPcd9aVhyu02YaDJgJiNTZh8p2I9o DnDbbSTvU7HNUs/SK6FnoAONkt7T3TKOyf5mSBHpLY9WJQOXjFNuv3jUSQfaTpB294Yu oRyZNSZY73I+TU2kQGPFLBiO0DljFPTnsGQzeNUEPry804PEOFghQxCVB+ISWvhPc1ip 1sDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition :arc-authentication-results; bh=/xL9QlNMkrDfXwO00cj9dhoa+eIFKX0FoRFEgLRY+Tc=; b=kE4d18hxTNddxiwWOFlUCPXT+k/z4k8BL/DlyoLpyGLoUv9fN9LWmXJuQaPLEAvtLe sv7C7eYABhdV/4C23ZQTaxTNrzuEKxuEh2GN21d98vvD4rYunEHGTa4T8Zg+QoGRLbzr Jdz/qIeZsYutURDm2hzYIFP0EFIiHo8LMEMVJGwdqmW+fJqulH+/GZEHY0VrhQcb6lBZ K0300vUsSxjjm7+Az3o3N/8LZ4MYhFX7TnbT7pr/NEO9LbLQWsCPp2fUvvfq6iq43NOV f3MND0H7215knmk5b+6V/eq0JSEnsQpWsxyS42GxABxe5AvHJUJJO+VL5MG6+UWTBW9e oqgw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t64si1207732pgb.294.2018.02.28.08.44.00; Wed, 28 Feb 2018 08:44:16 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932409AbeB1QC7 (ORCPT + 99 others); Wed, 28 Feb 2018 11:02:59 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:34732 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932224AbeB1QCz (ORCPT ); Wed, 28 Feb 2018 11:02:55 -0500 Received: from [2a02:8011:400e:2:6f00:88c8:c921:d332] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1er3Yk-0006Xc-7v; Wed, 28 Feb 2018 15:22:23 +0000 Received: from ben by deadeye with local (Exim 4.90_1) (envelope-from ) id 1er3Yi-0000DJ-SX; Wed, 28 Feb 2018 15:22:20 +0000 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Steffen Klassert" , "Herbert Xu" Date: Wed, 28 Feb 2018 15:20:18 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 180/254] xfrm: Return error on unknown encap_type in init_state In-Reply-To: X-SA-Exim-Connect-IP: 2a02:8011:400e:2:6f00:88c8:c921:d332 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.55-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Herbert Xu commit bcfd09f7837f5240c30fd2f52ee7293516641faa upstream. Currently esp will happily create an xfrm state with an unknown encap type for IPv4, without setting the necessary state parameters. This patch fixes it by returning -EINVAL. There is a similar problem in IPv6 where if the mode is unknown we will skip initialisation while returning zero. However, this is harmless as the mode has already been checked further up the stack. This patch removes this anomaly by aligning the IPv6 behaviour with IPv4 and treating unknown modes (which cannot actually happen) as transport mode. Fixes: 38320c70d282 ("[IPSEC]: Use crypto_aead and authenc in ESP") Signed-off-by: Herbert Xu Signed-off-by: Steffen Klassert Signed-off-by: Ben Hutchings --- net/ipv4/esp4.c | 1 + net/ipv6/esp6.c | 3 +-- 2 files changed, 2 insertions(+), 2 deletions(-) --- a/net/ipv4/esp4.c +++ b/net/ipv4/esp4.c @@ -657,6 +657,7 @@ static int esp_init_state(struct xfrm_st switch (encap->encap_type) { default: + err = -EINVAL; goto error; case UDP_ENCAP_ESPINUDP: x->props.header_len += sizeof(struct udphdr); --- a/net/ipv6/esp6.c +++ b/net/ipv6/esp6.c @@ -600,13 +600,12 @@ static int esp6_init_state(struct xfrm_s x->props.header_len += IPV4_BEET_PHMAXLEN + (sizeof(struct ipv6hdr) - sizeof(struct iphdr)); break; + default: case XFRM_MODE_TRANSPORT: break; case XFRM_MODE_TUNNEL: x->props.header_len += sizeof(struct ipv6hdr); break; - default: - goto error; } align = ALIGN(crypto_aead_blocksize(aead), 4);