Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp698482pxb; Tue, 2 Feb 2021 15:59:38 -0800 (PST) X-Google-Smtp-Source: ABdhPJywRP5eu3Gla01E81dGhvmHcEw0uV6wxLMb6ssJtHKvfEaxZjeegTHSVjqmZzzc+TnPbQMU X-Received: by 2002:a17:906:b351:: with SMTP id cd17mr488911ejb.110.1612310377873; Tue, 02 Feb 2021 15:59:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612310377; cv=none; d=google.com; s=arc-20160816; b=soe9xFubegG4yTJ703tZe3rgLDfLCKGbVK9CZDHR9OuMo4EG0dy3zxTlS14IKmjYjG xxtNe+hlQYXi4FeDbrs5FuvGDOEWFYdV5RCuzLNDMhTyhkLtPJND5IXiK0iAT/87xBrp NTcdCI+SLLgSRlsFnMmzlO0TY7v7zMdoe+UPbRKIrc2fDrkyAHUVKo37K4Mto6Gpv432 MHG/dvewnsW1qUTgREPeeV6I0EEgJp+B4UtZntQW0eR2YnDIyEPbTL8v/uuqbZMz4sUf l4XOnqEWTeYMqcOuEAUobt5me2ubw1lH2k0M1PbacFcPwZLeZWRwkFWP8DzVzdJxp5rN nkbw== 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=hQ5Lg8TiirqtxT0s7Eaq+KHe44ZRPOEilFfsK+Pm4Xs=; b=ijg2mxAALhv5NlfQTnoDw/HkXBWRCnZMbLClDcwR4nYSrNE7+pMQpldvDuOZZFCeaU U7Ss/5460DVGJQP6ftv3cIyPt1pKPmZd8v12HlOt6xO0oIaHe6l51JlHLDcP/vatwwrT KURIqcRX8vHnhHK7qB7nRcjHJbPNYo8aQH2QFyjefsL7ialY9JV2AylfIrpidSV3gUPY 11+Ip1yVeWOBxwanSNANAWd6wTpsKsrlIyMDvkBBC3rSph+Ctvw/xnaVs+wtA+9dTTSP PK75sdAYWabhKfzG0iM9jYqk1FL6bgdRQHhmgKgYMQ4ExTThY+8ef++2QExqympcVf5W HCYA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=M0t8AY8E; 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 l22si171209edr.554.2021.02.02.15.59.13; Tue, 02 Feb 2021 15:59:37 -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=M0t8AY8E; 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 S237671AbhBBRg7 (ORCPT + 99 others); Tue, 2 Feb 2021 12:36:59 -0500 Received: from mail.kernel.org ([198.145.29.99]:49180 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234137AbhBBOMe (ORCPT ); Tue, 2 Feb 2021 09:12:34 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id A9A486503E; Tue, 2 Feb 2021 13:52:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1612273943; bh=xjls9VuBhy1pm20NufPbxHSC/pVfoAicENrFZljS6wA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=M0t8AY8EGvGXKoBgP4dxuGmsh/ECPNyCMVuBTozK/aMB/QVnKoLwP+KA16Sq4sSSP JFWdHrnbqGjkyQXrxvgwnnqqkNryc8NOcp1YXQM7jOFNoCvke/VOhQWMETxGJolkS0 QHKZ1j4nvOFGU7me2Mqsk2ry0SS1oJFwY+jwbpZM= 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 4.14 17/30] xfrm: Fix oops in xfrm_replay_advance_bmp Date: Tue, 2 Feb 2021 14:38:58 +0100 Message-Id: <20210202132942.843997469@linuxfoundation.org> X-Mailer: git-send-email 2.30.0 In-Reply-To: <20210202132942.138623851@linuxfoundation.org> References: <20210202132942.138623851@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 874735742152d..594b8b2c32c85 100644 --- a/net/xfrm/xfrm_input.c +++ b/net/xfrm/xfrm_input.c @@ -415,7 +415,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