Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp1349115pxf; Fri, 19 Mar 2021 05:25:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw/wAex/JuZ+XKEnC1h6PHhy6ys6I9IHJVeEzs1ieuIrcYPUD5PHYXdqt8DhqumlaSlrnEw X-Received: by 2002:a05:6402:5211:: with SMTP id s17mr9265009edd.327.1616156733983; Fri, 19 Mar 2021 05:25:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616156733; cv=none; d=google.com; s=arc-20160816; b=qpo1KDk3sPQH82zHFKz20W+XOF3MWX+ObWnMqR76egqAIMGizRA5N1EaMGwpRMYHcP vUA/TaDIss3ZQqH0YVAwtkXh4o751PoTi5XkR34F0EBIhU8WHwnv0ZDsDDSS5dY2oBVw WW9dQ8B6HFOpwaUpR2KayNY+yCd/1jz57DwMiYgoT6+B5rCjP9um9B3fy7h8ioO933T/ QFK/Dt3vnzjwZC9zPSYlGQMkA7AyZdyy1B18NORs1EVWZzAYKcR+BhglM1hPgD50iNgm TIqYUFeM08eS5x/ixQGPlVQGlX9ZfJ9GvJuoH3vA8ezSUGK6/NP0LgezNWCcEwQqUQro E9ZQ== 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=5s1bTQXUmKjjSypx8f3DDPWtrPi28c6g08iM7tBJjn0=; b=qfLQOUWt3WSaw2jCFyyfTZ3a/OPrqvTy30mmAVb3JK6bBsfLWuKeVdWE114h/go1Vv rsTNpOLXJ57Z1OCTBN3HXZ/zk//OLBUeXwVYeZaPZ4kt+WIdkcwGYYOEGCTKgT1zqixD OuPVYvuOtIl6NLwWf94pV/zcsIf+OLYdR/ga7EJU9lTRaf2ey03iJ9VWs9TxCrwb22oz fSkbh5A+FEJrasfMso6xKYRIAXqC8N46JrYYttuXdaESHJX+EZiA8OGBmnU4Yndw9USO 2M7I6siNBrzjz1Jo3dWfK2+aawhOpY3ssl34F0OCYX1+sZWJmQA50zPaKRoLv4WCvAq4 l9tw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=SMzs4ZHE; 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 x14si4226274edd.207.2021.03.19.05.25.11; Fri, 19 Mar 2021 05:25:33 -0700 (PDT) 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=SMzs4ZHE; 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 S231681AbhCSMWJ (ORCPT + 99 others); Fri, 19 Mar 2021 08:22:09 -0400 Received: from mail.kernel.org ([198.145.29.99]:60450 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231442AbhCSMVc (ORCPT ); Fri, 19 Mar 2021 08:21:32 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 7927264F72; Fri, 19 Mar 2021 12:21:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1616156491; bh=MpSJKd9BjNGBC8GLwiKMzUKdtXHwXJNj6Z5vol6Rn6Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SMzs4ZHERQ3aX18rG/YkkFR7KNgtI3sNA9W3ULfjuLsqlMbaZ89J8UqigbRpIKpPz a4O66s3ERh73jGLqXDHxOu0RwfPmJqu75a6foHfWLJrzZNvlhlSbTPEr4QtXKAUVma eErvwC/pMrq4xLOZpS2Dfbtz07rus1jzGbzsryPw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Piotr Krysiuk , Daniel Borkmann , Alexei Starovoitov Subject: [PATCH 5.11 20/31] bpf: Prohibit alu ops for pointer types not defining ptr_limit Date: Fri, 19 Mar 2021 13:19:14 +0100 Message-Id: <20210319121747.854374700@linuxfoundation.org> X-Mailer: git-send-email 2.31.0 In-Reply-To: <20210319121747.203523570@linuxfoundation.org> References: <20210319121747.203523570@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: Piotr Krysiuk commit f232326f6966cf2a1d1db7bc917a4ce5f9f55f76 upstream. The purpose of this patch is to streamline error propagation and in particular to propagate retrieve_ptr_limit() errors for pointer types that are not defining a ptr_limit such that register-based alu ops against these types can be rejected. The main rationale is that a gap has been identified by Piotr in the existing protection against speculatively out-of-bounds loads, for example, in case of ctx pointers, unprivileged programs can still perform pointer arithmetic. This can be abused to execute speculatively out-of-bounds loads without restrictions and thus extract contents of kernel memory. Fix this by rejecting unprivileged programs that attempt any pointer arithmetic on unprotected pointer types. The two affected ones are pointer to ctx as well as pointer to map. Field access to a modified ctx' pointer is rejected at a later point in time in the verifier, and 7c6967326267 ("bpf: Permit map_ptr arithmetic with opcode add and offset 0") only relevant for root-only use cases. Risk of unprivileged program breakage is considered very low. Fixes: 7c6967326267 ("bpf: Permit map_ptr arithmetic with opcode add and offset 0") Fixes: b2157399cc98 ("bpf: prevent out-of-bounds speculation") Signed-off-by: Piotr Krysiuk Co-developed-by: Daniel Borkmann Signed-off-by: Daniel Borkmann Acked-by: Alexei Starovoitov Signed-off-by: Greg Kroah-Hartman --- kernel/bpf/verifier.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -5462,6 +5462,7 @@ static int sanitize_ptr_alu(struct bpf_v u32 alu_state, alu_limit; struct bpf_reg_state tmp; bool ret; + int err; if (can_skip_alu_sanitation(env, insn)) return 0; @@ -5477,10 +5478,13 @@ static int sanitize_ptr_alu(struct bpf_v alu_state |= ptr_is_dst_reg ? BPF_ALU_SANITIZE_SRC : BPF_ALU_SANITIZE_DST; - if (retrieve_ptr_limit(ptr_reg, &alu_limit, opcode, off_is_neg)) - return 0; - if (update_alu_sanitation_state(aux, alu_state, alu_limit)) - return -EACCES; + err = retrieve_ptr_limit(ptr_reg, &alu_limit, opcode, off_is_neg); + if (err < 0) + return err; + + err = update_alu_sanitation_state(aux, alu_state, alu_limit); + if (err < 0) + return err; do_sim: /* Simulate and find potential out-of-bounds access under * speculative execution from truncation as a result of @@ -5596,7 +5600,7 @@ static int adjust_ptr_min_max_vals(struc case BPF_ADD: ret = sanitize_ptr_alu(env, insn, ptr_reg, dst_reg, smin_val < 0); if (ret < 0) { - verbose(env, "R%d tried to add from different maps or paths\n", dst); + verbose(env, "R%d tried to add from different maps, paths, or prohibited types\n", dst); return ret; } /* We can take a fixed offset as long as it doesn't overflow @@ -5651,7 +5655,7 @@ static int adjust_ptr_min_max_vals(struc case BPF_SUB: ret = sanitize_ptr_alu(env, insn, ptr_reg, dst_reg, smin_val < 0); if (ret < 0) { - verbose(env, "R%d tried to sub from different maps or paths\n", dst); + verbose(env, "R%d tried to sub from different maps, paths, or prohibited types\n", dst); return ret; } if (dst_reg == off_reg) {