Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp726025pxb; Tue, 2 Feb 2021 16:49:45 -0800 (PST) X-Google-Smtp-Source: ABdhPJwDjjX5Fzu4mqhFxwR4obleb9jvw0+sK5KMqqFdJOQtbS1y3j66m5GJHqxsS96kYk06luPY X-Received: by 2002:a17:906:8690:: with SMTP id g16mr601280ejx.113.1612313385801; Tue, 02 Feb 2021 16:49:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612313385; cv=none; d=google.com; s=arc-20160816; b=mhxDWOOLjzesA6XWHEZsGfOXzz9WxEJfMzcRQ3illDcbfCeKAC8l4RqlAT73VV2L0V I1SWE1+XQpA13Csv4bDHgK+U7K/Bwyi4Lk72B5QE5P1Cix3/fQ8MSlGPNncdGbwwYrSr uKLPSdNh4r20D7m/VKJvD+wa9hHWGOc5GFdMxK+WV2aqNH/Yn8OXZwryZ6Kkwsi0Edsh EBupHZtFbgfPh1Z6KBwCgP2gcx5xmJGZE//TZyIEnauMuNLSS+Gb3B8+GaAcRyopByDc d1M9GACqGJND1j4IQPrpOCIlV/lW4CGpSnWUyrXCH/f5CAGpb71PIexx2lzDQ8AQxr2E UYoQ== 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=MujIcpFBb4QaWnML5xGa6FYHJzs7kK3reOT2YZc4emI=; b=IwY32JzPxVKyzOnIaDerviKebs3A1WnO+2GpMpyb5LGWB6vsTqJjPu9Sect7OJIZTk 6ffBfdyfP/ykzsncBGXdxIs5+bhcuvZrdFXfSkfr87xgmt6mI9UjTBKObc3SWqKfXZk5 pZ/JL2ciZR5S0ggLVbqFLFpBx3sv5s/tlHHHu5WzNCfDEyUuR/sRKGrLIXudD3NitFP4 EfpzA2y0biDacuBTmIZrlCSk4hKbVcV/wbpsb1vdmelmGWS3bn0Voe0XgK9N7EIBfzuf fS1gNcUMaaC4shi+Ia66clhOaKTx/W2JjSBiQ4NUav5icnPRHu3HM9rFGfuPf6KVQAGD WSHw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="Qh2Ju/r/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s1si269071ejq.292.2021.02.02.16.48.59; Tue, 02 Feb 2021 16:49:45 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="Qh2Ju/r/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240001AbhBBTnd (ORCPT + 99 others); Tue, 2 Feb 2021 14:43:33 -0500 Received: from mail.kernel.org ([198.145.29.99]:40700 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233272AbhBBNx0 (ORCPT ); Tue, 2 Feb 2021 08:53:26 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 24E8764FCB; Tue, 2 Feb 2021 13:44:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1612273446; bh=Y5g0K2kIHO1Yvult+K6kvCAozywjd/W7LH+QmaO2Ed0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Qh2Ju/r/53XikYcFwncxkFnS9c+uE+UCH9xqpkJLbAArmkuauJfP2JcbmGoM9acD6 Tf6hh3lGY1Oxz8S2DYIu0jWE4qW6nVVNQQoJrCviIkPFQ/a6XRZYsK6Avuf3nZiYhr Uf7NstHI2MPKJ868+U98iJrbmKbPW5++EHHs0qu0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Shmulik Ladkani , Steffen Klassert , Sasha Levin Subject: [PATCH 5.10 078/142] xfrm: Fix oops in xfrm_replay_advance_bmp Date: Tue, 2 Feb 2021 14:37:21 +0100 Message-Id: <20210202133000.926674036@linuxfoundation.org> X-Mailer: git-send-email 2.30.0 In-Reply-To: <20210202132957.692094111@linuxfoundation.org> References: <20210202132957.692094111@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Shmulik Ladkani [ Upstream commit 56ce7c25ae1525d83cf80a880cf506ead1914250 ] When setting xfrm replay_window to values higher than 32, a rare page-fault occurs in xfrm_replay_advance_bmp: BUG: unable to handle page fault for address: ffff8af350ad7920 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD ad001067 P4D ad001067 PUD 0 Oops: 0002 [#1] SMP PTI CPU: 3 PID: 30 Comm: ksoftirqd/3 Kdump: loaded Not tainted 5.4.52-050452-generic #202007160732 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 RIP: 0010:xfrm_replay_advance_bmp+0xbb/0x130 RSP: 0018:ffffa1304013ba40 EFLAGS: 00010206 RAX: 000000000000010d RBX: 0000000000000002 RCX: 00000000ffffff4b RDX: 0000000000000018 RSI: 00000000004c234c RDI: 00000000ffb3dbff RBP: ffffa1304013ba50 R08: ffff8af330ad7920 R09: 0000000007fffffa R10: 0000000000000800 R11: 0000000000000010 R12: ffff8af29d6258c0 R13: ffff8af28b95c700 R14: 0000000000000000 R15: ffff8af29d6258fc FS: 0000000000000000(0000) GS:ffff8af339ac0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff8af350ad7920 CR3: 0000000015ee4000 CR4: 00000000001406e0 Call Trace: xfrm_input+0x4e5/0xa10 xfrm4_rcv_encap+0xb5/0xe0 xfrm4_udp_encap_rcv+0x140/0x1c0 Analysis revealed offending code is when accessing: replay_esn->bmp[nr] |= (1U << bitnr); with 'nr' being 0x07fffffa. This happened in an SMP system when reordering of packets was present; A packet arrived with a "too old" sequence number (outside the window, i.e 'diff > replay_window'), and therefore the following calculation: bitnr = replay_esn->replay_window - (diff - pos); yields a negative result, but since bitnr is u32 we get a large unsigned quantity (in crash dump above: 0xffffff4b seen in ecx). This was supposed to be protected by xfrm_input()'s former call to: if (x->repl->check(x, skb, seq)) { However, the state's spinlock x->lock is *released* after '->check()' is performed, and gets re-acquired before '->advance()' - which gives a chance for a different core to update the xfrm state, e.g. by advancing 'replay_esn->seq' when it encounters more packets - leading to a 'diff > replay_window' situation when original core continues to xfrm_replay_advance_bmp(). An attempt to fix this issue was suggested in commit bcf66bf54aab ("xfrm: Perform a replay check after return from async codepaths"), by calling 'x->repl->recheck()' after lock is re-acquired, but fix applied only to asyncronous crypto algorithms. Augment the fix, by *always* calling 'recheck()' - irrespective if we're using async crypto. Fixes: 0ebea8ef3559 ("[IPSEC]: Move state lock into x->type->input") Signed-off-by: Shmulik Ladkani Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin --- net/xfrm/xfrm_input.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c index 37456d022cfa3..61e6220ddd5ae 100644 --- a/net/xfrm/xfrm_input.c +++ b/net/xfrm/xfrm_input.c @@ -660,7 +660,7 @@ resume: /* only the first xfrm gets the encap type */ encap_type = 0; - if (async && x->repl->recheck(x, skb, seq)) { + if (x->repl->recheck(x, skb, seq)) { XFRM_INC_STATS(net, LINUX_MIB_XFRMINSTATESEQERROR); goto drop_unlock; } -- 2.27.0