netdev - Re: [PATCH bpf-next v11 02/12] bpf: use the least significant byte for the nr

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <2815478.mvXUDI8C0e@7950hx>
Date: Sat, 24 Jan 2026 09:14:04 +0800
From: Menglong Dong <menglong.dong@...ux.dev>
To: Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc: menglong8.dong@...il.com, andrii@...nel.org, bot+bpf-ci@...nel.org,
 daniel@...earbox.net, martin.lau@...ux.dev, eddyz87@...il.com,
 song@...nel.org, yonghong.song@...ux.dev, john.fastabend@...il.com,
 kpsingh@...nel.org, sdf@...ichev.me, haoluo@...gle.com, jolsa@...nel.org,
 davem@...emloft.net, dsahern@...nel.org, tglx@...utronix.de,
 mingo@...hat.com, jiang.biao@...ux.dev, bp@...en8.de,
 dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com,
 bpf@...r.kernel.org, netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
 ast@...nel.org, martin.lau@...nel.org, clm@...a.com, ihor.solodrai@...ux.dev
Subject:
 Re: [PATCH bpf-next v11 02/12] bpf: use the least significant byte for the
 nr_args in trampoline

On 2026/1/24 06:57, Andrii Nakryiko wrote:
> On Fri, Jan 23, 2026 at 1:21 AM Menglong Dong <menglong.dong@...ux.dev> wrote:
> >
> > On 2026/1/23 16:29 Menglong Dong <menglong.dong@...ux.dev> write:
> > > On 2026/1/23 16:07 bot+bpf-ci@...nel.org write:
> > > > > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > > > > index 41bbed6418b5..b3f912ad18ba 100644
> > > > > --- a/kernel/bpf/verifier.c
> > > > > +++ b/kernel/bpf/verifier.c
> > > >
> > > > [ ... ]
> > > >
> > > > > @@ -23779,12 +23781,13 @@ static int do_misc_fixups(struct bpf_verifier_env *env)
> > > > >                       eatype == BPF_MODIFY_RETURN) {
> > > > >                           /* Load nr_args from ctx - 8 */
> > > > >                           insn_buf[0] = BPF_LDX_MEM(BPF_DW, BPF_REG_0, BPF_REG_1, -8);
> > > > > -                         insn_buf[1] = BPF_ALU64_IMM(BPF_LSH, BPF_REG_0, 3);
> > > > > +                         insn_buf[1] = BPF_ALU64_IMM(BPF_AND, BPF_REG_0, 0xFF);
> > > > > +                         insn_buf[2] = BPF_ALU64_IMM(BPF_LSH, BPF_REG_0, 3);
> > > >
> > > > [ ... ]
> > > >
> > > > > -                         cnt = 6;
> > > > > +                         cnt = 7;
> > > > >                   } else {
> > > > >                           insn_buf[0] = BPF_MOV64_IMM(BPF_REG_0, -EOPNOTSUPP);
> > > > >                           cnt = 1;
> > > > >                   }
> > > > >
> > > > >                   new_prog = bpf_patch_insn_data(env, i + delta, insn_buf, cnt);
> > > >
> > > > [ ... ]
> > > >
> > > > >                   delta    += cnt - 1;
> > > >
> > > > Note that the bpf_get_func_ret block above correctly updates delta after
> > > > patching.
> > > >
> > > > > @@ -23808,12 +23811,15 @@ static int do_misc_fixups(struct bpf_verifier_env *env)
> > > > >
> > > > >                           /* skip 'void *__data' in btf_trace_##name() and save to reg0 */
> > > > >                           insn_buf[0] = BPF_MOV64_IMM(BPF_REG_0, nr_args - 1);
> > > > > +                         cnt = 1;
> > > > >                   } else {
> > > > >                           /* Load nr_args from ctx - 8 */
> > > > >                           insn_buf[0] = BPF_LDX_MEM(BPF_DW, BPF_REG_0, BPF_REG_1, -8);
> > > > > +                         insn_buf[1] = BPF_ALU64_IMM(BPF_AND, BPF_REG_0, 0xFF);
> > > > > +                         cnt = 2;
> > > > >                   }
> > > > >
> > > > > -                 new_prog = bpf_patch_insn_data(env, i + delta, insn_buf, 1);
> > > > > +                 new_prog = bpf_patch_insn_data(env, i + delta, insn_buf, cnt);
> > > > >                   if (!new_prog)
> > > > >                           return -ENOMEM;
> > > > >
> > > > >                   env->prog = prog = new_prog;
> > > > >                   insn      = new_prog->insnsi + i + delta;
> > > > >                   goto next_insn;
> > > > >           }
> > > >
> > > > Should there be a "delta += cnt - 1;" before assigning env->prog in this
> > > > bpf_get_func_arg_cnt block? When cnt is 2 (non-RAW_TP path), the program
> > > > grows by one instruction, but delta is not updated. This could cause
> > > > subsequent bpf_patch_insn_data() calls to use incorrect offsets.
> > > >
> > > > The bpf_get_func_arg block at the beginning of this patch has:
> > > >
> > > >     delta    += cnt - 1;
> > > >     env->prog = prog = new_prog;
> > > >
> > > > And the bpf_get_func_ret block similarly has delta updated. But this
> > > > bpf_get_func_arg_cnt block goes directly to env->prog assignment without
> > > > updating delta.
> > >
> > > Ah, good point, I think this is a valid problem. The selftests didn't cover
> > > this case, and I think I'd better to use bpf_get_func_arg() and bpf_get_func_ret()
> > > in the exit path of fsession to cover it.
> >
> > Oh, the problem doesn't have much impact. The only impact
> > is that the verifier will check the "r0 &= 0xFF" instruction redundantly.
> >
> > I'll see if there is more comment before I send next version.
> >
> 
> Let's still fix the problem. Just go ahead and resubmit (with the fix
> and improved test).

OK!

> 
> pw-bot: cr
> 
> 
> > Thanks!
> > Menglong Dong
> >
> > >
> > > Will fix it in the next version.
> > >
> > > Thanks!
> > > Menglong Dong
> > >
> > > >
> > > >
> > > > ---
> > > > AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> > > > See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
> > > >
> > > > CI run summary: https://github.com/kernel-patches/bpf/actions/runs/21278745581
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> 
>