[bpf-next,v2,2/2] selftests/bpf: check null propagation only neither reg is PTR_TO_BTF_ID
Message ID | 20221213030436.17907-2-sunhao.th@gmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp2604530wrr; Mon, 12 Dec 2022 19:13:30 -0800 (PST) X-Google-Smtp-Source: AA0mqf63NXuSTnLuQ92qji07zdltrCwbruAQJ5/LL7r22D92rmO4UIg7vlz003h9sujPlSuxwpTq X-Received: by 2002:a17:906:190e:b0:7c1:65ce:7f9f with SMTP id a14-20020a170906190e00b007c165ce7f9fmr7847486eje.65.1670901210320; Mon, 12 Dec 2022 19:13:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670901210; cv=none; d=google.com; s=arc-20160816; b=Pz2PqAEIjHmWWST6ik+oG5lqES3yogKgv8KiSGivt8QmrAu1qWhOH/WD6TIDoAhmmr VtUsdbd40zTXq3khjwb5Wo5TU6ZMCZtxZsVX0423bYiVE145NuLjjvp6BZBTpJ3lwASy Qz4LLOk7QaR6M/MtElMClra4+4Ed3wowhgavcIwmtcPl+zo+l2Q/egqByR6QxUGDuk8I YvY3KoXVlFkDr89TsVR48MO8m4lZ4Z8dvAgGellNDQwnMjsNhwTB01kOu0yzy0bTA5d8 /LsTj5ZHqZmk7rOhCXx+lYJ0MC6BYii2G90K5wlnqqKODQbDxVy2UTEHsN2eLJ0SmbJ5 aqzw== 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 :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=n8wKW76JtFs2F5+hWCFZWeal4WDxfruIrmk6Ywx4Si4=; b=znBAcOJKYVRsGhL/UaE57WKLkd3vUDcBJsp2jqdadzlFp7unz0SnAqZHpXyruFBZrz 0PQYWxwP0RBtOKViak+GZReVndOAQOhvt8NQvYcGuNyTw1CVFFe5oTB7YlwY1oZ7RzqJ u7BAZJ1zgJnoUEnmz4MH/gxWMmGKcinDz1slm8HEUkzTX7knUNZ78AXKBZZ0MvwTM+mP wJA65PiaGJgFT/80mPDD7HZ+zSwjKAwMYkofpiHjrxbFJDkG4xy+L6If1MUrYhF540UH t8gWI0A6CAfIkw13tOzTYjHgTlUJE8XqINmqDWVwg71xhWxatr5aH2IfDU2eeRN23wrz ryQw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=nMyvyxUJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j17-20020a05640211d100b00462848f0cdbsi11496299edw.299.2022.12.12.19.13.06; Mon, 12 Dec 2022 19:13:30 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=nMyvyxUJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234440AbiLMDFn (ORCPT <rfc822;jeantsuru.cumc.mandola@gmail.com> + 99 others); Mon, 12 Dec 2022 22:05:43 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60336 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234387AbiLMDFc (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 12 Dec 2022 22:05:32 -0500 Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 173B81A209; Mon, 12 Dec 2022 19:05:31 -0800 (PST) Received: by mail-pj1-x1032.google.com with SMTP id u15-20020a17090a3fcf00b002191825cf02so2124552pjm.2; Mon, 12 Dec 2022 19:05:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=n8wKW76JtFs2F5+hWCFZWeal4WDxfruIrmk6Ywx4Si4=; b=nMyvyxUJTgQlDMX08Le+mw3awdPBeGMcnKlhZx4cReQRGaNqBtTgMabpUeS++olgHa gIrQubgHL+pXSdRjAQpL7sKpal0+oOfxKX2KhmxIWH01fKapkp6k+LWWH3lBk5/DhXyG /UcG06Gtd+CBtBM1Mrs2l2Ocm9muOTfhOMFZvmLv3WCPgNt8rhj29ABSSHMHrxN8vJE2 +o7O3ibuJOJmeQZpVo9ad9uTQ3EfkcSmcxU2OekPSJKcx9l1hUm5pLRlxHg1m5QwymDW 3VwVw+5+tOgbYfMbdoQnBfE4sYJA0ldZ08bh2yQIeDyU7qye/7sYLBzzkaMKSTDqfD3E PcYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=n8wKW76JtFs2F5+hWCFZWeal4WDxfruIrmk6Ywx4Si4=; b=UPwAQEbdvsa5yhz6W+vZFSzXU6pp8/B1wF3NbrfYqfiSnBC5feshNdhXRb2m9U6oQM BcFuRKENGYz+Jv4WnuHoPriQcoK5J8wQpDIyCeDC4/0D1voC7Qd6uVgSX9O0pibMFSzD uG3dhrGtoh7ArMjfThEb7MeR0GRGEp+ML2uRSkYLOa58IrPzNFxAKp5pIH+IGPnQnfMm QHBIm7E2yWYQfVEl9JvJnNb5t10H1IDfGaCCg50lTqTGXJ6BX8FG6N04JtS22MCNOteT 9wj+xM0T8866GVZ89ahABU34DmVDprzO5OcO8sNCwazWZqtK05qydFnmb5SP8tZIakQQ aXXw== X-Gm-Message-State: ANoB5pm/OjaF9EagP++Uf9JDII+SsZsIa7h5RXRdC9OMy2r7sZwwE21t IY+ixh4xZFqaQZ/xY+jEMCPgVZ35Y22V X-Received: by 2002:a05:6a21:3397:b0:a5:70ed:bda9 with SMTP id yy23-20020a056a21339700b000a570edbda9mr32647414pzb.26.1670900730224; Mon, 12 Dec 2022 19:05:30 -0800 (PST) Received: from localhost.localdomain ([144.214.0.6]) by smtp.gmail.com with ESMTPSA id z21-20020aa79495000000b005746c3b2445sm6481716pfk.151.2022.12.12.19.05.27 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Mon, 12 Dec 2022 19:05:29 -0800 (PST) From: Hao Sun <sunhao.th@gmail.com> To: bpf@vger.kernel.org Cc: ast@kernel.org, daniel@iogearbox.net, john.fastabend@gmail.com, andrii@kernel.org, martin.lau@linux.dev, song@kernel.org, yhs@fb.com, kpsingh@kernel.org, sdf@google.com, haoluo@google.com, jolsa@kernel.org, davem@davemloft.net, linux-kernel@vger.kernel.org, Hao Sun <sunhao.th@gmail.com> Subject: [PATCH bpf-next v2 2/2] selftests/bpf: check null propagation only neither reg is PTR_TO_BTF_ID Date: Tue, 13 Dec 2022 11:04:36 +0800 Message-Id: <20221213030436.17907-2-sunhao.th@gmail.com> X-Mailer: git-send-email 2.37.1 (Apple Git-137.1) In-Reply-To: <20221213030436.17907-1-sunhao.th@gmail.com> References: <20221213030436.17907-1-sunhao.th@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1752066907612439483?= X-GMAIL-MSGID: =?utf-8?q?1752066907612439483?= |
Series |
[bpf-next,v2,1/2] bpf: fix nullness propagation for reg to reg comparisons
|
|
Commit Message
Hao Sun
Dec. 13, 2022, 3:04 a.m. UTC
Verify that nullness information is not porpagated in the branches of register to register JEQ and JNE operations if one of them is PTR_TO_BTF_ID. Signed-off-by: Hao Sun <sunhao.th@gmail.com> Acked-by: Yonghong Song <yhs@fb.com> --- .../bpf/verifier/jeq_infer_not_null.c | 22 +++++++++++++++++++ 1 file changed, 22 insertions(+)
Comments
On 12/12/22 7:04 PM, Hao Sun wrote: > Verify that nullness information is not porpagated in the branches > of register to register JEQ and JNE operations if one of them is > PTR_TO_BTF_ID. Thanks for the fix and test. > > Signed-off-by: Hao Sun <sunhao.th@gmail.com> > Acked-by: Yonghong Song <yhs@fb.com> > --- > .../bpf/verifier/jeq_infer_not_null.c | 22 +++++++++++++++++++ > 1 file changed, 22 insertions(+) > > diff --git a/tools/testing/selftests/bpf/verifier/jeq_infer_not_null.c b/tools/testing/selftests/bpf/verifier/jeq_infer_not_null.c > index 67a1c07ead34..b2b215227d97 100644 > --- a/tools/testing/selftests/bpf/verifier/jeq_infer_not_null.c > +++ b/tools/testing/selftests/bpf/verifier/jeq_infer_not_null.c > @@ -172,3 +172,25 @@ > .prog_type = BPF_PROG_TYPE_XDP, > .result = ACCEPT, > }, > +{ > + "jne/jeq infer not null, PTR_TO_MAP_OR_NULL unchanged with PTR_TO_BTF_ID reg", > + .insns = { > + BPF_MOV64_REG(BPF_REG_2, BPF_REG_10), > + BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8), > + BPF_ST_MEM(BPF_DW, BPF_REG_2, 0, 0), > + BPF_LD_MAP_FD(BPF_REG_1, 0), > + /* r6 = bpf_map->inner_map_meta; */ > + BPF_LDX_MEM(BPF_DW, BPF_REG_6, BPF_REG_1, 8), This bpf_map->inner_map_meta requires CO-RE. It works now but could be fragile in different platform and in the future bpf_map changes. Take a look at the map_ptr_kern.c which uses "__attribute__((preserve_access_index))" at the "struct bpf_map". Please translate this verifer test into a proper bpf prog in C code such that it can use the CO-RE in libbpf. It should run under test_progs instead of test_verifier. The bpf prog can include the "vmlinux.h" to get the "__attribute__((preserve_access_index))" for free. Take a look at https://lore.kernel.org/all/20221207201648.2990661-2-andrii@kernel.org/ which has example on how to check verifier message in test_progs. > + /* r0 = map_lookup_elem(r1, r2); */ > + BPF_EMIT_CALL(BPF_FUNC_map_lookup_elem), > + /* if (r0 == r6) read *r0; */ > + BPF_JMP_REG(BPF_JEQ, BPF_REG_6, BPF_REG_0, 1), > + BPF_EXIT_INSN(), > + BPF_LDX_MEM(BPF_W, BPF_REG_0, BPF_REG_0, 0), > + BPF_EXIT_INSN(), > + }, > + .fixup_map_hash_8b = { 3 }, > + .prog_type = BPF_PROG_TYPE_XDP, > + .result = REJECT, > + .errstr = "R0 invalid mem access 'map_value_or_null'", > +},
> On 20 Dec 2022, at 6:01 AM, Martin KaFai Lau <martin.lau@linux.dev> wrote: > > On 12/12/22 7:04 PM, Hao Sun wrote: >> Verify that nullness information is not porpagated in the branches >> of register to register JEQ and JNE operations if one of them is >> PTR_TO_BTF_ID. > > Thanks for the fix and test. > >> Signed-off-by: Hao Sun <sunhao.th@gmail.com> >> Acked-by: Yonghong Song <yhs@fb.com> >> --- >> .../bpf/verifier/jeq_infer_not_null.c | 22 +++++++++++++++++++ >> 1 file changed, 22 insertions(+) >> diff --git a/tools/testing/selftests/bpf/verifier/jeq_infer_not_null.c b/tools/testing/selftests/bpf/verifier/jeq_infer_not_null.c >> index 67a1c07ead34..b2b215227d97 100644 >> --- a/tools/testing/selftests/bpf/verifier/jeq_infer_not_null.c >> +++ b/tools/testing/selftests/bpf/verifier/jeq_infer_not_null.c >> @@ -172,3 +172,25 @@ >> .prog_type = BPF_PROG_TYPE_XDP, >> .result = ACCEPT, >> }, >> +{ >> + "jne/jeq infer not null, PTR_TO_MAP_OR_NULL unchanged with PTR_TO_BTF_ID reg", >> + .insns = { >> + BPF_MOV64_REG(BPF_REG_2, BPF_REG_10), >> + BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8), >> + BPF_ST_MEM(BPF_DW, BPF_REG_2, 0, 0), >> + BPF_LD_MAP_FD(BPF_REG_1, 0), >> + /* r6 = bpf_map->inner_map_meta; */ >> + BPF_LDX_MEM(BPF_DW, BPF_REG_6, BPF_REG_1, 8), > > This bpf_map->inner_map_meta requires CO-RE. It works now but could be fragile in different platform and in the future bpf_map changes. Take a look at the map_ptr_kern.c which uses "__attribute__((preserve_access_index))" at the "struct bpf_map". > > Please translate this verifer test into a proper bpf prog in C code such that it can use the CO-RE in libbpf. It should run under test_progs instead of test_verifier. The bpf prog can include the "vmlinux.h" to get the "__attribute__((preserve_access_index))" for free. Take a look at https://lore.kernel.org/all/20221207201648.2990661-2-andrii@kernel.org/ which has example on how to check verifier message in test_progs. > Sure, thanks for the hint, will send patch v3 soon. Thanks Hao
> On 20 Dec 2022, at 6:01 AM, Martin KaFai Lau <martin.lau@linux.dev> wrote: > > On 12/12/22 7:04 PM, Hao Sun wrote: >> Verify that nullness information is not porpagated in the branches >> of register to register JEQ and JNE operations if one of them is >> PTR_TO_BTF_ID. > > Thanks for the fix and test. > >> Signed-off-by: Hao Sun <sunhao.th@gmail.com> >> Acked-by: Yonghong Song <yhs@fb.com> >> --- >> .../bpf/verifier/jeq_infer_not_null.c | 22 +++++++++++++++++++ >> 1 file changed, 22 insertions(+) >> diff --git a/tools/testing/selftests/bpf/verifier/jeq_infer_not_null.c b/tools/testing/selftests/bpf/verifier/jeq_infer_not_null.c >> index 67a1c07ead34..b2b215227d97 100644 >> --- a/tools/testing/selftests/bpf/verifier/jeq_infer_not_null.c >> +++ b/tools/testing/selftests/bpf/verifier/jeq_infer_not_null.c >> @@ -172,3 +172,25 @@ >> .prog_type = BPF_PROG_TYPE_XDP, >> .result = ACCEPT, >> }, >> +{ >> + "jne/jeq infer not null, PTR_TO_MAP_OR_NULL unchanged with PTR_TO_BTF_ID reg", >> + .insns = { >> + BPF_MOV64_REG(BPF_REG_2, BPF_REG_10), >> + BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8), >> + BPF_ST_MEM(BPF_DW, BPF_REG_2, 0, 0), >> + BPF_LD_MAP_FD(BPF_REG_1, 0), >> + /* r6 = bpf_map->inner_map_meta; */ >> + BPF_LDX_MEM(BPF_DW, BPF_REG_6, BPF_REG_1, 8), > > This bpf_map->inner_map_meta requires CO-RE. It works now but could be fragile in different platform and in the future bpf_map changes. Take a look at the map_ptr_kern.c which uses "__attribute__((preserve_access_index))" at the "struct bpf_map". > > Please translate this verifer test into a proper bpf prog in C code such that it can use the CO-RE in libbpf. It should run under test_progs instead of test_verifier. The bpf prog can include the "vmlinux.h" to get the "__attribute__((preserve_access_index))" for free. Take a look at https://lore.kernel.org/all/20221207201648.2990661-2-andrii@kernel.org/ which has example on how to check verifier message in test_progs. > Hi, I’ve tried something like the bellow, but soon realized that this won’t work because once compiler figures out `inner_map` equals to `val`, it can choose either reg to write into in the following path, meaning that this program can be rejected due to writing into read-only PTR_TO_BTF_ID reg, and this makes the test useless. Essentially, we want two regs, one points to PTR_TO_BTD_ID, one points to MAP_VALUR_OR_NULL, then compare them and deref map val. It’s hard to implement this in C level because compilers decide which reg to use but not us, maybe we can just drop this test. thoughts? +struct { + __uint(type, BPF_MAP_TYPE_HASH); + __uint(max_entries, 1); + __type(key, u64); + __type(value, u64); +} m_hash SEC(".maps"); + +SEC("?raw_tp") +__failure __msg("invalid mem access 'map_value_or_null") +int jeq_infer_not_null_ptr_to_btfid(void *ctx) +{ + struct bpf_map *map = (struct bpf_map *)&m_hash; + struct bpf_map *inner_map = map->inner_map_meta; + u64 key = 0, ret = 0, *val; + + val = bpf_map_lookup_elem(map, &key); + /* Do not mark ptr as non-null if one of them is + * PTR_TO_BTF_ID, reject because of invalid access + * to map value. + */ + if (val == inner_map) + ret = *val; + + return ret; +}
On 12/21/22 5:46 AM, Hao Sun wrote: > Hi, > > I’ve tried something like the bellow, but soon realized that this > won’t work because once compiler figures out `inner_map` equals > to `val`, it can choose either reg to write into in the following > path, meaning that this program can be rejected due to writing > into read-only PTR_TO_BTF_ID reg, and this makes the test useless. hmm... I read the above a few times but I still don't quite get it. In particular, '...can be rejected due to writing into read-only PTR_TO_BTF_ID reg...'. Where is it writing into a read-only PTR_TO_BTF_ID reg in the following bpf prog? Did I overlook something? > > Essentially, we want two regs, one points to PTR_TO_BTD_ID, one > points to MAP_VALUR_OR_NULL, then compare them and deref map val. If I read this request correctly, I guess the compiler has changed 'ret = *val' to 'ret = *inner_map'? Thus, the verifier did not reject because it deref a PTR_TO_BTF_ID? > It’s hard to implement this in C level because compilers decide > which reg to use but not us, maybe we can just drop this test. Have you tried inline assembly. Something like this (untested): asm volatile ( "r8 = %[val];\n" "r9 = %[inner_map];\n" "if r8 != r9 goto +1;\n" "%[ret] = *(u64 *)(r8 +0);\n" :[ret] "+r"(ret) : [inner_map] "r"(inner_map), [val] "r"(val) :"r8", "r9"); Please attach the verifier output in the future. It will be easier to understand. > > thoughts? > > +struct { > + __uint(type, BPF_MAP_TYPE_HASH); > + __uint(max_entries, 1); > + __type(key, u64); > + __type(value, u64); > +} m_hash SEC(".maps"); > + > +SEC("?raw_tp") > +__failure __msg("invalid mem access 'map_value_or_null") > +int jeq_infer_not_null_ptr_to_btfid(void *ctx) > +{ > + struct bpf_map *map = (struct bpf_map *)&m_hash; > + struct bpf_map *inner_map = map->inner_map_meta; > + u64 key = 0, ret = 0, *val; > + > + val = bpf_map_lookup_elem(map, &key); > + /* Do not mark ptr as non-null if one of them is > + * PTR_TO_BTF_ID, reject because of invalid access > + * to map value. > + */ > + if (val == inner_map) > + ret = *val; > + > + return ret; > +}
Martin KaFai Lau <martin.lau@linux.dev> 于2022年12月22日周四 05:21写道: > > On 12/21/22 5:46 AM, Hao Sun wrote: > > Hi, > > > > I’ve tried something like the bellow, but soon realized that this > > won’t work because once compiler figures out `inner_map` equals > > to `val`, it can choose either reg to write into in the following > > path, meaning that this program can be rejected due to writing > > into read-only PTR_TO_BTF_ID reg, and this makes the test useless. > > hmm... I read the above a few times but I still don't quite get it. In > particular, '...can be rejected due to writing into read-only PTR_TO_BTF_ID > reg...'. Where is it writing into a read-only PTR_TO_BTF_ID reg in the > following bpf prog? Did I overlook something? > > > > > Essentially, we want two regs, one points to PTR_TO_BTD_ID, one > > points to MAP_VALUR_OR_NULL, then compare them and deref map val. > > If I read this request correctly, I guess the compiler has changed 'ret = *val' > to 'ret = *inner_map'? Thus, the verifier did not reject because it deref a > PTR_TO_BTF_ID? > Yes, and if we do "*val = 0", it's rejected due to writing to read-only PTR_TO_BTF_ID reg. > > It’s hard to implement this in C level because compilers decide > > which reg to use but not us, maybe we can just drop this test. > > Have you tried inline assembly. Something like this (untested): > > asm volatile ( > "r8 = %[val];\n" > "r9 = %[inner_map];\n" > "if r8 != r9 goto +1;\n" > "%[ret] = *(u64 *)(r8 +0);\n" > :[ret] "+r"(ret) > : [inner_map] "r"(inner_map), [val] "r"(val) > :"r8", "r9"); > This would work, didn't realize that I can inline BPF insns this way. Thanks! > Please attach the verifier output in the future. It will be easier to understand. > Will do the next time.
diff --git a/tools/testing/selftests/bpf/verifier/jeq_infer_not_null.c b/tools/testing/selftests/bpf/verifier/jeq_infer_not_null.c index 67a1c07ead34..b2b215227d97 100644 --- a/tools/testing/selftests/bpf/verifier/jeq_infer_not_null.c +++ b/tools/testing/selftests/bpf/verifier/jeq_infer_not_null.c @@ -172,3 +172,25 @@ .prog_type = BPF_PROG_TYPE_XDP, .result = ACCEPT, }, +{ + "jne/jeq infer not null, PTR_TO_MAP_OR_NULL unchanged with PTR_TO_BTF_ID reg", + .insns = { + BPF_MOV64_REG(BPF_REG_2, BPF_REG_10), + BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8), + BPF_ST_MEM(BPF_DW, BPF_REG_2, 0, 0), + BPF_LD_MAP_FD(BPF_REG_1, 0), + /* r6 = bpf_map->inner_map_meta; */ + BPF_LDX_MEM(BPF_DW, BPF_REG_6, BPF_REG_1, 8), + /* r0 = map_lookup_elem(r1, r2); */ + BPF_EMIT_CALL(BPF_FUNC_map_lookup_elem), + /* if (r0 == r6) read *r0; */ + BPF_JMP_REG(BPF_JEQ, BPF_REG_6, BPF_REG_0, 1), + BPF_EXIT_INSN(), + BPF_LDX_MEM(BPF_W, BPF_REG_0, BPF_REG_0, 0), + BPF_EXIT_INSN(), + }, + .fixup_map_hash_8b = { 3 }, + .prog_type = BPF_PROG_TYPE_XDP, + .result = REJECT, + .errstr = "R0 invalid mem access 'map_value_or_null'", +},