On Wed, Mar 18, 2026 at 2:39 PM Morten Brørup <[email protected]>
wrote:
>
> > From: Marat Khalili [mailto:[email protected]]
> > Sent: Wednesday, 18 March 2026 14.07
> >
> > > > Handling immediate as unsigned is questionable, especially in the
> > > > BPF_IND case
> > > > it may produce incorrect results.
> > >
> > > In Classic BPF (cBPF), when the immediate "k" is negative (when cast
> > to signed integer), it is used
> > > for getting packet metadata (e.g. SKF_AD_VLAN_TAG gets the VLAN ID);
> > otherwise it is considered
> > > unsigned.
> >
> > Yes. Since we don't support it, we should probably consider these
> > offsets invalid.
>
> +1
>
> >
> > And in the BPF_IND case one might be tempted to load end of some packet
> > area in
> > the register and use negative offsets, we probably should handle it
> > correctly.
>
> In Classic BPF, negative "k" has special meaning for both BPF_ABS and BPF_IND.
> So we should consider it invalid for both cases.
>
> That prevents applications from using it the way you describe.
> And it will allow us to add BPF library support for Linux-compatible special
> meanings later, without breaking the ABI.
>
Aren't these invalid offsets already taken care during the syntax
check when we validate the BPF program ?
in bpf_validate.c +1499:
/* load absolute instructions */
[(BPF_LD | BPF_ABS | BPF_B)] = {
.mask = {. dreg = ZERO_REG, .sreg = ZERO_REG},
.off = { .min = 0, .max = 0},
.imm = { .min = 0, .max = INT32_MAX},
.eval = eval_ld_mbuf,
},
IIUC, as __rte_bpf_validate fails when we cal rte_bpf_load ( in
bpf_load.c +113), we can't even interpret the cBPF program.
> >
> > > > To make things worse, `__rte_pktmbuf_read` is also buggy when
> > passed
> > > > very large
> > > > lengths (again, technically not ARM eBPF fault).
> > >
> > > Are you referring to the potential integer wraparound in the off+len
> > > rte_pktmbuf_pkt_len(m)
> > > comparison?
> > > [BZ1724]
> > > Or some other bug in __rte_pktmbuf_read()?
> > >
> > > [BZ1724]: https://bugs.dpdk.org/show_bug.cgi?id=1724
> >
> > Technically that one manifested itself in rte_pktmbuf_read (without
> > underscores), but essentially the root cause is the same. In the eBPF
> > BPF_ABS
> > case we could potentially rely on `__rte_pktmbuf_read` for refusing to
> > accept
> > negative values converted to large integers, but due to overflows we
> > cannot.
>
> Agree.
>
> The off+len wraparound in rte_pktmbuf_read() and __rte_pktmbuf_read() is
> clearly a bug, and not intentional.
> Reading the function documentation supports the conclusion that the
> wraparound is a bug; the off and len parameters are unsigned, and the
> documentation says nothing about an ability to make them behave as signed.
>
