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;
Message-ID: <7137c191-49c6-7f57-95bc-ee15c7af3c28@meta.com>
Date:   Wed, 4 Jan 2023 08:51:38 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.6.1
Subject: Re: WARNING in __mark_chain_precision
Content-Language: en-US
To:     Hao Sun <sunhao.th@gmail.com>
Cc:     Alexei Starovoitov <alexei.starovoitov@gmail.com>,
        Andrii Nakryiko <andrii.nakryiko@gmail.com>,
        Stanislav Fomichev <sdf@google.com>,
        Andrii Nakryiko <andrii@kernel.org>, bpf <bpf@vger.kernel.org>,
        Alexei Starovoitov <ast@kernel.org>,
        Daniel Borkmann <daniel@iogearbox.net>,
        John Fastabend <john.fastabend@gmail.com>,
        Martin KaFai Lau <martin.lau@linux.dev>,
        Song Liu <song@kernel.org>, Yonghong Song <yhs@fb.com>,
        KP Singh <kpsingh@kernel.org>, Hao Luo <haoluo@google.com>,
        Jiri Olsa <jolsa@kernel.org>,
        David Miller <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>,
        Jesper Dangaard Brouer <hawk@kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
References: <CACkBjsaXNceR8ZjkLG=dT3P=4A8SBsg0Z5h5PWLryF5=ghKq=g@mail.gmail.com>
 <Y6C36gvJ2JnwKm3X@google.com>
 <CAEf4BzbY8SDL04W_3Vot6iiYu69Lqg9W9aMCp26+RwLBh6C_0g@mail.gmail.com>
 <ba5aacc8-7e10-e20a-936b-f3f81d7fcf03@meta.com>
 <CAEf4BzY-DMVEpy+mPTObEO56E7=fzqab8zW_4JyBeyGtTqqcXg@mail.gmail.com>
 <29B647B3-174A-4BE7-9E0E-83AE94B0EADF@gmail.com>
 <04c66278-b044-98e4-2861-218bd159bd15@meta.com>
 <CB67D529-B384-4B1C-AC01-DD99D4F6DEA5@gmail.com>
 <CAADnVQKy48LPz=f6XSHv84tZb7MFp8PrWrk3AxJLKwJR0tL=nA@mail.gmail.com>
 <44be9647-0208-beaf-130d-92a036c95d04@meta.com>
 <0A63A5B8-DD57-4A8E-BC40-EF112F691E6A@gmail.com>
From:   Yonghong Song <yhs@meta.com>
In-Reply-To: <0A63A5B8-DD57-4A8E-BC40-EF112F691E6A@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VDJ4TnNqVzJwcVdMclBLUUk5MXZXV2hiKzA5YWRDdWxyUmx4STdPZzlyR2tP?=
 =?utf-8?B?M29mYmxTUk9RU3pRMlpvcUtRa0xaTEtqWXhzdzNBWnpmcDVTRkxCZitCOGx4?=
 =?utf-8?B?Sm1vNUk0VW43dzRhR1Ruc3pDL3BVWGZRVHp6ZXAydEo0eHF1MGQvbnBWVTh0?=
 =?utf-8?B?b2pHRlFSeFAxZjhOSjBvWjlYdmEvWWlleHFKM2dDYktlVEh4bDNkY2FkdGVX?=
 =?utf-8?B?aDZNQVlJaE9KWUVXMHpGei9wZ0xxZ2VORUFKMnJkdzRodU0yNjFxZ3pmdlgx?=
 =?utf-8?B?WEo3VG10Y3dvWEIzdzBGZE02c2lPcnAyWEJaZ1owNlE4Z0JNclVLQW9paHRw?=
 =?utf-8?B?THU1UjZhWmQ1S3Q2ZG5ZSmFNK05KeVlLdG9NVEFFYVZBbExLVTRrY21JZEs3?=
 =?utf-8?B?UkRTdnYzOTBUQ0JUKy9tUnU3TzhDdXJoZm9oenRldGdwZmMzcms2cnR3SjRN?=
 =?utf-8?B?OFNGU3VPNEZ0L2l5YkdxK2xoaXVRLzFWVUJBUlBuVEpGN1JXNjh5cks1NUNn?=
 =?utf-8?B?bFdzbjVSaVUwL3FPeXJOamlWYzMxSUNUdFhiUDA5M1ZVWXlVZGs2amJ5MWlR?=
 =?utf-8?B?dkE2YUNYZHhQVW1HbWMyZmZtNkIwYVdHM2s5ZTNWUnNuMTAzcEtBM1FQOTZU?=
 =?utf-8?B?REptR2wvS3JGWFU1ZCs0cTJFajdKK1hNOFpOU2ZDbWY3YVc5NmQyR3psUS83?=
 =?utf-8?B?WWMyM092dlh6TldOZTNSeVJrSVJuK0xGQUU2Y2pGazBzQ0hzcmhzTjE4a0tm?=
 =?utf-8?B?cWVHOU1UZGR5NnFZa1h2Zno2SUd0ci9IMEtaMHI3VlVsd1lVZHNxdzhEbnJF?=
 =?utf-8?B?Skx6WTliVGVqZTFIU1F6OGoydHdBUnhabkNJL1VlaWF0UVY0Y2ZSanE5SVhs?=
 =?utf-8?B?TndJbXRHOTFxOU1sNXRGMVROSjhsSTVFdkhqS3dnVE9abHpqWG5vNkMwSUE2?=
 =?utf-8?B?MjhFWHNYWE5EUllWSkorTjFRYTc5czE4VWU4NVhOSytHV1lqNy8vSlJMSFlr?=
 =?utf-8?B?bUFDVlM4OWQvVGhzWXhaOW56RlZtdlBWOTRab2VQeldVNDdQL20wQ2JGVGp5?=
 =?utf-8?B?a1FsRzE0MTlvT0RrOUZNQ0tUdWR3SHMva3dEc0lkRjR1dTRySWpSY08wdzZt?=
 =?utf-8?B?S0d4OFV5d0NrSTlFODZzVGc3VDNwTnppdi9XWkJGamNVOWtqdXY4a3VkRE9Z?=
 =?utf-8?B?emZYbVQ1UXZheklWeWxTdWVJOXFRL05oQ0NEVzQ5bU5QM2JQRjk3cXBBVVBJ?=
 =?utf-8?B?RjkzVXJUREZSTEZrQzJpY2ZYNXhWWi9qd3FhQ2piMDQzZDErbjJTS0lBbzR0?=
 =?utf-8?B?ZWhGclhLcVpsbTFMY3hwOWxiT0grc0RqeG5XSmFVU2k5anB5aWpWc0tiVzRB?=
 =?utf-8?B?K3JXTHZkZGhLSGE2QVBBVjlOZm93V0dnZXJPUWZqVTViTVhBR0Q5UnJTZGZ3?=
 =?utf-8?B?RkF4cHVtU1pPelJpRllVcnNJZ2lqM1dYYm9LTFlmSW9Ybk9Na2pIM3NKcTB2?=
 =?utf-8?B?dVI3L0hQQTdjTEh1TnptTjhLQWdjeFEvN3RrOTlCYTIwRThVM2sydno0Zlg3?=
 =?utf-8?B?YXJmVm9ZMlJDR0FGdXpXZEplM0I0SFFERk5tRnlOeHI4cmZsU1NlcVE0allt?=
 =?utf-8?B?R0tUWEpCN0ZEQ0xkZGU0QVZVM3hqTDRqNmVUZG15YVdZcmJ0QnIvTDRTZ0NN?=
 =?utf-8?B?ZXlhRkNnMjA4NVBhREI1OTd2V0R6djlBNWwvVmM5cHJyRWJGRGlSbm9EY2pu?=
 =?utf-8?B?b2pVTVVob0RSTndmK2FyTEVFWHNZUFRFMEVwRGhuWG9DNE1sc2E4SGxDMnp0?=
 =?utf-8?B?WVZxQjlMbW1RdndaZ0JSajdQbWVNTzlGU2RBQWZjcjAwU1puZjJJcTBVSWxx?=
 =?utf-8?B?M0NLRG1JbGZLUFR0dUZXcFZKVlVkNmlONkNBM1R0QVJxN3NuL1dEdXVDdkFB?=
 =?utf-8?B?anBOR2VBNytZSHllOXpsbzRwWDc4OVZHNmxxa3hHT0d2cUh0enhBUW9lWUVI?=
 =?utf-8?B?WXJ0MFdObzVZdnU2bVpnd1lpeldxYzhJeTVNaGprWk5jQXI0bzZ6aFFvZXZO?=
 =?utf-8?B?QTVQV1NMbzlocDBUQU1ueVM0d0t5Q2lWZ2U3Qy9lbjBlYUxIN1l6SERGdHpw?=
 =?utf-8?B?eWxiTE9nbDBGUjlJc3MvcSswMW5nWVhNZlZWaGJ6SGdQZHhUVlB3OGsyVEdB?=
 =?utf-8?B?T1E9PQ==?=
X-OriginatorOrg: meta.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2f9e22b5-9239-4b18-7c94-08daee73f46f
X-MS-Exchange-CrossTenant-AuthSource: SN6PR1501MB2064.namprd15.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Jan 2023 16:51:41.7661
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: d7/WgDdvBhZyuJrEOAB/0+/haQH6daYIsD2A9+Mt5+PRG4ZC+YXvweEI/FDAR825
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR15MB1291
X-Proofpoint-GUID: UiPCa2-hhNEjDo0ZE42zvxgj6QVqbcUu
X-Proofpoint-ORIG-GUID: UiPCa2-hhNEjDo0ZE42zvxgj6QVqbcUu
Content-Transfer-Encoding: 8bit
X-Proofpoint-UnRewURL: 3 URL's were un-rewritten
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.923,Hydra:6.0.545,FMLib:17.11.122.1
 definitions=2023-01-04_07,2023-01-04_02,2022-06-22_01
X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE
        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


On 1/4/23 12:52 AM, Hao Sun wrote:
> 
> 
>> On 4 Jan 2023, at 1:47 PM, Yonghong Song <yhs@meta.com> wrote:
>>
>>
>>
>> On 1/3/23 10:27 AM, Alexei Starovoitov wrote:
>>> On Mon, Jan 2, 2023 at 1:42 AM Hao Sun <sunhao.th@gmail.com> wrote:
>>>>
>>>>
>>>>
>>>> Yonghong Song <yhs@meta.com> 于2023年1月2日周一 03:20写道：
>>>>>
>>>>>
>>>>>
>>>>> On 12/30/22 1:44 AM, Hao Sun wrote:
>>>>>>
>>>>>>
>>>>>> Andrii Nakryiko <andrii.nakryiko@gmail.com> 于2022年12月30日周五 06:16写道：
>>>>>>>
>>>>>>> On Tue, Dec 27, 2022 at 9:24 PM Yonghong Song <yhs@meta.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 12/20/22 4:30 PM, Andrii Nakryiko wrote:
>>>>>>>>> On Mon, Dec 19, 2022 at 11:13 AM <sdf@google.com> wrote:
>>>>>>>>>>
>>>>>>>>>> On 12/19, Hao Sun wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>>> The following backtracking bug can be triggered on the latest bpf-next and
>>>>>>>>>>> Linux 6.1 with the C prog provided. I don't have enough knowledge about
>>>>>>>>>>> this part in the verifier, don't know how to fix this.
>>>>>>>>>>
>>>>>>>>>> Maybe something related to commit be2ef8161572 ("bpf: allow precision
>>>>>>>>>> tracking
>>>>>>>>>> for programs with subprogs") and/or the related ones?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> This can be reproduced on:
>>>>>>>>>>
>>>>>>>>>>> HEAD commit: 0e43662e61f2 tools/resolve_btfids: Use pkg-config to locate
>>>>>>>>>>> libelf
>>>>>>>>>>> git tree: bpf-next
>>>>>>>>>>> console log: https://pastebin.com/raw/45hZ7iqm
>>>>>>>>>>> kernel config: https://pastebin.com/raw/0pu1CHRm
>>>>>>>>>>> C reproducer: https://pastebin.com/raw/tqsiezvT
>>>>>>>>>>
>>>>>>>>>>> func#0 @0
>>>>>>>>>>> 0: R1=ctx(off=0,imm=0) R10=fp0
>>>>>>>>>>> 0: (18) r2 = 0x8000000000000          ; R2_w=2251799813685248
>>>>>>>>>>> 2: (18) r6 = 0xffff888027358000       ;
>>>>>>>>>>> R6_w=map_ptr(off=0,ks=3032,vs=3664,imm=0)
>>>>>>>>>>> 4: (18) r7 = 0xffff88802735a000       ;
>>>>>>>>>>> R7_w=map_ptr(off=0,ks=156,vs=2624,imm=0)
>>>>>>>>>>> 6: (18) r8 = 0xffff88802735e000       ;
>>>>>>>>>>> R8_w=map_ptr(off=0,ks=2396,vs=76,imm=0)
>>>>>>>>>>> 8: (18) r9 = 0x8e9700000000           ; R9_w=156779191205888
>>>>>>>>>>> 10: (36) if w9 >= 0xffffffe3 goto pc+1
>>>>>>>>>>> last_idx 10 first_idx 0
>>>>>>>>>>> regs=200 stack=0 before 8: (18) r9 = 0x8e9700000000
>>>>>>>>>>> 11: R9_w=156779191205888
>>>>>>>>>>> 11: (85) call #0
>>>>>>>>>>> 12: (cc) w2 s>>= w7
>>>>>>>>>
>>>>>>>>> w2 should have been set to NOT_INIT (because r1-r5 are clobbered by
>>>>>>>>> calls) and rejected here as !read_ok (see check_reg_arg()) before
>>>>>>>>> attempting to mark precision for r2. Can you please try to debug and
>>>>>>>>> understand why that didn't happen here?
>>>>>>>>
>>>>>>>> The verifier is doing the right thing here and the 'call #0' does
>>>>>>>> implicitly cleared r1-r5.
>>>>>>>>
>>>>>>>> So for 'w2 s>>= w7', since w2 is used, the verifier tries to find
>>>>>>>> its definition by backtracing. It encountered 'call #0', which clears
>>>>>>>
>>>>>>> and that's what I'm saying is incorrect. Normally we'd get !read_ok
>>>>>>> error because s>>= is both READ and WRITE on w2, which is
>>>>>>> uninitialized after call instruction according to BPF ABI. And that's
>>>>>>> what actually seems to happen correctly in my (simpler) tests locally.
>>>>>>> But something is special about this specific repro that somehow either
>>>>>>> bypasses this logic, or attempts to mark precision before we get to
>>>>>>> that test. That's what we should investigate. I haven't tried to run
>>>>>>> this specific repro locally yet, so can't tell for sure.
>>>>>>>
>>>>>>
>>>>>> So, the reason why w2 is not marked as uninit is that the kfunc call in
>>>>>> the BPF program is invalid, "call #0", imm is zero, right?
>>>>>
>>>>> Yes, "call #0" is invalid. As the code below
>>>>>
>>>>>> /* skip for now, but return error when we find this in
>>>>> fixup_kfunc_call */
>>>>>>   if (!insn->imm)
>>>>>>   return 0;
>>>>>
>>>>> The error report will be delayed later in fixup_kfunc_call().
>>>>>
>>>>> static int fixup_kfunc_call(struct bpf_verifier_env *env, struct
>>>>> bpf_insn *insn,
>>>>>                              struct bpf_insn *insn_buf, int insn_idx,
>>>>> int *cnt)
>>>>> {
>>>>>          const struct bpf_kfunc_desc *desc;
>>>>>
>>>>>          if (!insn->imm) {
>>>>>                  verbose(env, "invalid kernel function call not
>>>>> eliminated in verifier pass\n");
>>>>>                  return -EINVAL;
>>>>>          }
>>>>>
>>>>>
>>>>>> In check_kfunc_call(), it skips this error temporarily:
>>>>>>
>>>>>> /* skip for now, but return error when we find this in fixup_kfunc_call */
>>>>>>   if (!insn->imm)
>>>>>>   return 0;
>>>>>>
>>>>>> So the kfunc call is the previous instruction before "w2 s>>= w7", this
>>>>>> leads to the warning in backtrack_insn():
>>>>>>
>>>>>> /* regular helper call sets R0 */
>>>>>> *reg_mask &= ~1;
>>>>>> if (*reg_mask & 0x3f) {
>>>>>>       /* if backtracing was looking for registers R1-R5
>>>>>>       * they should have been found already.
>>>>>>       */
>>>>>>       verbose(env, "BUG regs %x\n", *reg_mask);
>>>>>>       WARN_ONCE(1, "verifier backtracking bug”);
>>>>>>       return -EFAULT;
>>>>>> }
>>>>>
>>>>> The main triggering the backtrack_insn() is due to
>>>>>
>>>>>                          } else {
>>>>>                                  /* scalar += pointer
>>>>>                                   * This is legal, but we have to
>>>>> reverse our
>>>>>                                   * src/dest handling in computing the range
>>>>>                                   */
>>>>>                                  err = mark_chain_precision(env,
>>>>> insn->dst_reg);
>>>>>                                  if (err)
>>>>>                                          return err;
>>>>>                                  return adjust_ptr_min_max_vals(env, insn,
>>>>>                                                                 src_reg,
>>>>> dst_reg);
>>>>>                          }
>>>>>
>>>>>
>>>>> unc#0 @0
>>>>> 0: R1=ctx(off=0,imm=0) R10=fp0
>>>>> 0: (18) r2 = 0x8000000000000          ; R2_w=2251799813685248
>>>>> 2: (18) r6 = 0xffff888100d29000       ;
>>>>> R6_w=map_ptr(off=0,ks=3032,vs=3664,imm=0)
>>>>> 4: (18) r7 = 0xffff888100d2a000       ;
>>>>> R7_w=map_ptr(off=0,ks=156,vs=2624,imm=0)
>>>>> 6: (18) r8 = 0xffff888100d2ac00       ;
>>>>> R8_w=map_ptr(off=0,ks=2396,vs=76,imm=0)
>>>>> 8: (18) r9 = 0x8e9700000000           ; R9_w=156779191205888
>>>>> 10: (36) if w9 >= 0xffffffe3 goto pc+1
>>>>> last_idx 10 first_idx 0
>>>>> regs=200 stack=0 before 8: (18) r9 = 0x8e9700000000
>>>>> 11: R9_w=156779191205888
>>>>> 11: (85) call #0
>>>>> 12: (cc) w2 s>>= w7
>>>>> last_idx 12 first_idx 12
>>>>> parent didn't have regs=4 stack=0 marks: R1=ctx(off=0,imm=0)
>>>>> R2_rw=P2251799813685248 R6_w=map_ptr(off=0,ks=3032,vs=3664,imm=0)
>>>>> R7_rw=map_ptr(off=0,ks=156,vs=2624,imm=0) R8_w=map_ptr(off=0,ks=2396,v0
>>>>> last_idx 11 first_idx 0
>>>>> regs=4 stack=0 before 11: (85) call #0
>>>>> BUG regs 4
>>>>>
>>>>> For insn 12, 'w2 s>>= w7', w2 is a scalar and w7 is a map_ptr. Hence,
>>>>> based on the above verifier code, mark_chain_precision() is triggered.
>>>>>
>>>>> Not sure what is the purpose of this test. But to make it succeed,
>>>>> first "call #0" need to change to a valid kfunc call, and second, you
>>>>> might want to change 'w2 s>>= w7' to e.g., 'w9 s>>= w7' to avoid
>>>>> precision tracking.
>>>>>
>>>>
>>>> The purpose is not to make the test "succeed", the verifier temporarily
>>>> skips the invalid kfunc insn "call #0", but this insn triggered a warning
>>>> in backtrack_insn(), while it is supposed to reject the program either
>>>> due to insn#12 32bit ptr alu or insn#11 invalid kfunc.
>>>>
>>>> Maybe something like the bellow, after applying the patch, the reproducer
>>>> is rejected:
>>>>
>>>> func#0 @0
>>>> 0: R1=ctx(off=0,imm=0) R10=fp0
>>>> 0: (18) r2 = 0x8000000000000          ; R2_w=2251799813685248
>>>> 2: (18) r6 = 0xffff88817d563000       ; R6_w=map_ptr(off=0,ks=3032,vs=3664,imm=0)
>>>> 4: (18) r7 = 0xffff888171ee9000       ; R7_w=map_ptr(off=0,ks=156,vs=2624,imm=0)
>>>> 6: (18) r8 = 0xffff888171ee8000       ; R8_w=map_ptr(off=0,ks=2396,vs=76,imm=0)
>>>> 8: (18) r9 = 0x8e9700000000           ; R9_w=156779191205888
>>>> 10: (36) if w9 >= 0xffffffe3 goto pc+1
>>>> last_idx 10 first_idx 0
>>>> regs=200 stack=0 before 8: (18) r9 = 0x8e9700000000
>>>> 11: R9_w=156779191205888
>>>> 11: (85) call #0
>>>> 12: (cc) w2 s>>= w7
>>>> last_idx 12 first_idx 12
>>>> parent didn't have regs=4 stack=0 marks: R1=ctx(off=0,imm=0) R2_rw=P2251799813685248 R6_w=map_ptr(off=0,ks=3032,vs=3664,imm=0) R7_rw=map_ptr(off=0,ks=156,vs=2624,imm=0) R8_w=map_ptr(off=0,ks=2396,vs=76,imm=0) R9_w=156779191205888 R10=fp0
>>>> last_idx 11 first_idx 0
>>>> regs=4 stack=0 before 11: (85) call #0
>>>> regs=4 stack=0 before 10: (36) if w9 >= 0xffffffe3 goto pc+1
>>>> regs=4 stack=0 before 8: (18) r9 = 0x8e9700000000
>>>> regs=4 stack=0 before 6: (18) r8 = 0xffff888171ee8000
>>>> regs=4 stack=0 before 4: (18) r7 = 0xffff888171ee9000
>>>> regs=4 stack=0 before 2: (18) r6 = 0xffff88817d563000
>>>> regs=4 stack=0 before 0: (18) r2 = 0x8000000000000
>>>> R2 32-bit pointer arithmetic prohibited
>>>> processed 8 insns (limit 1000000) max_states_per_insn 0 total_states 1 peak_states 1 mark_read 1
>>>>
>>>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>>>> index 4a25375ebb0d..abc7e96d826f 100644
>>>> --- a/kernel/bpf/verifier.c
>>>> +++ b/kernel/bpf/verifier.c
>>>> @@ -2743,6 +2743,9 @@ static int backtrack_insn(struct bpf_verifier_env *env, int idx,
>>>>                          *reg_mask |= sreg;
>>>>          } else if (class == BPF_JMP || class == BPF_JMP32) {
>>>>                  if (opcode == BPF_CALL) {
>>>> +                       /* skip for now, should return error when we find this in fixup_kfunc_call */
>>>> +                       if (insn->src_reg == BPF_PSEUDO_KFUNC_CALL && insn->imm == 0)
>>>> +                               return 0;
>>> Makes sense to me. Please submit as an official patch
>>> with s/return 0/return -ENOTSUPP/
>>> Also 'skip for now' isn't quite correct here.
>>> In check_kfunc_call() it's correct, since invalid kfunc with imm==0
>>> could be eliminated during dead code elimination,
>>> but since we're walking this insn here in backtrack_insn
>>> the dead code elimination is not going to kick in.
>>> So it's surely invalid kfunc call if we see it in backtrack_insn.
>>> The comment should probably be something like:
>>> /* kfunc with imm==0 is invalid and fixup_kfunc_call will catch
>>> this error later. Make backtracking conservative with ENOTSUPP. */
>>
>> Do we have the same issue if we have
>>    call #1 <or some valid kfunc>
>> instead of
>>    call #0
>> ?
> 
> Seems no. If that happened, then, it’s another bug. Because as Andrii commented,
> the prog should be rejected due to !read_ok before backing track to the kfunc
> call. In this particular case, the invalid kfunc call is skipped without marking
> Regs as uninitiated so the verifier incorrectly backtrack to that invalid call.

Make sense. Thanks for double checking!