Received: by 2002:a5d:9c59:0:0:0:0:0 with SMTP id 25csp107063iof; Sun, 5 Jun 2022 22:35:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx5JLLQTT13kh+7ah5kDmYn/zqLB7F2cAU5eZlTNJI2RNolWl3d0rx8hn4gXuXCbdgFxbvH X-Received: by 2002:a17:902:a585:b0:14d:58ef:65 with SMTP id az5-20020a170902a58500b0014d58ef0065mr22404038plb.139.1654493749771; Sun, 05 Jun 2022 22:35:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654493749; cv=none; d=google.com; s=arc-20160816; b=AwHLXQrK3l48t3EUR7HNXBmBCplJrt8Yq1kLSoCWfQtbiANG8BZ0iqChuDuz/c7oEQ 1Jlhje+PEzWA6SoHjV+5PDobFr2ygxLZSF65yJ1372Kjcha9lX8GPEMseKSD+E/TOIw1 PmuD+/EFbtRrmoa0NfD3znXLV/UepHttZAStiLglG261w8pL6AUYshzYGK1enYPhzrZE poWvjAG7Hp9pM3yyuTxTWvcJkgEtNRqoFMxZt8lGvdcGu5/q+50NguZy8jac10l4tD6+ iOXC8XBXBCl+i/THMzapROTMXW+iE84lZ4Kpc/pTASBOHd7Kay+TUCCFF9fYnK41LijR veMg== 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=EHhYE5WmaxiLyaQZ7j4Lj2WEpsoTFcAaIuq8HmFkGd4=; b=dPLA4MIbb7Hr2jRS2O/YY6Np4SPVGKgVljDU8ab7Gz++QSNQY5FW8BkB5MV/tCwGuL 0onuLdb0ecEDzOkSyxCO6dpmnO38HE2uNAQ+OFowWgVE491U/tAkCRBcMX7p/AVz0ejr EyslxsIJy8HngcbiDupk7NUyJQrQimz2VMIPleJf5QyI1uF/Uqx/W4Cxjqmro+dvR7cg Pgy3i6PGmsaRfAJbP/Gx6lyRC3vzNbdKqcnz9ENPYexkfM0jvWbv2gP4b2J30EwxIIPY hkkd9hoxT5prcIrZJ808qJ36K8EQN+BuErAcGL3K2gryFaeXLNFkRUHUB1AjsjvnptXX Vemw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="MSo/r6lk"; 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 n20-20020a17090aab9400b001cb6940edb6si18958872pjq.13.2022.06.05.22.35.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Jun 2022 22:35:49 -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="MSo/r6lk"; 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 8446623A015; Sun, 5 Jun 2022 21:36:26 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244655AbiFCSTM (ORCPT + 99 others); Fri, 3 Jun 2022 14:19:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45276 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348160AbiFCSGm (ORCPT ); Fri, 3 Jun 2022 14:06:42 -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 B2FF8580ED; Fri, 3 Jun 2022 10:59:54 -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 28831B82369; Fri, 3 Jun 2022 17:59:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6E9C2C385A9; Fri, 3 Jun 2022 17:59:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654279145; bh=o55eYgmVhHvolPaEPQyRiu/SsiwcIdehGA0DAyJ0Ytw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MSo/r6lklyO2rrJNMUSXsLSfJtd9u2hvqi2vKXurpnuWrC3l6Wggfr8e03BCaXOa2 8pBU9+9XCdhhGrOX//gS5dhJlP7syyI2owDvo3RpzODnjQiHO64h3Opxj2gdeSwzTp ExXEAf6Xo9qB1aEDcH2+rX4q6lecXajd+n0dkDtI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Hao Luo , Kumar Kartikeya Dwivedi , Alexei Starovoitov Subject: [PATCH 5.18 66/67] bpf: Check PTR_TO_MEM | MEM_RDONLY in check_helper_mem_access Date: Fri, 3 Jun 2022 19:44:07 +0200 Message-Id: <20220603173822.614061520@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220603173820.731531504@linuxfoundation.org> References: <20220603173820.731531504@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: Kumar Kartikeya Dwivedi commit 97e6d7dab1ca4648821c790a2b7913d6d5d549db upstream. The commit being fixed was aiming to disallow users from incorrectly obtaining writable pointer to memory that is only meant to be read. This is enforced now using a MEM_RDONLY flag. For instance, in case of global percpu variables, when the BTF type is not struct (e.g. bpf_prog_active), the verifier marks register type as PTR_TO_MEM | MEM_RDONLY from bpf_this_cpu_ptr or bpf_per_cpu_ptr helpers. However, when passing such pointer to kfunc, global funcs, or BPF helpers, in check_helper_mem_access, there is no expectation MEM_RDONLY flag will be set, hence it is checked as pointer to writable memory. Later, verifier sets up argument type of global func as PTR_TO_MEM | PTR_MAYBE_NULL, so user can use a global func to get around the limitations imposed by this flag. This check will also cover global non-percpu variables that may be introduced in kernel BTF in future. Also, we update the log message for PTR_TO_BUF case to be similar to PTR_TO_MEM case, so that the reason for error is clear to user. Fixes: 34d3a78c681e ("bpf: Make per_cpu_ptr return rdonly PTR_TO_MEM.") Reviewed-by: Hao Luo Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20220319080827.73251-3-memxor@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Greg Kroah-Hartman --- kernel/bpf/verifier.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -4876,13 +4876,23 @@ static int check_helper_mem_access(struc return check_map_access(env, regno, reg->off, access_size, zero_size_allowed); case PTR_TO_MEM: + if (type_is_rdonly_mem(reg->type)) { + if (meta && meta->raw_mode) { + verbose(env, "R%d cannot write into %s\n", regno, + reg_type_str(env, reg->type)); + return -EACCES; + } + } return check_mem_region_access(env, regno, reg->off, access_size, reg->mem_size, zero_size_allowed); case PTR_TO_BUF: if (type_is_rdonly_mem(reg->type)) { - if (meta && meta->raw_mode) + if (meta && meta->raw_mode) { + verbose(env, "R%d cannot write into %s\n", regno, + reg_type_str(env, reg->type)); return -EACCES; + } max_access = &env->prog->aux->max_rdonly_access; } else {