Re: [PATCH v4,bpf-next] bpf: Don't redirect packets with invalid pkt_len

[shaozhengchao]

On 2022/9/17 23:46, Stanislav Fomichev wrote:
> On Wed, Sep 14, 2022 at 4:20 AM Lorenz Bauer <oss@xxxxxx> wrote:
> > Hi,
> >
> > I think this patch is causing user-space breakage, see [0].
> >
> > The gist is that we do BPF_PROG_RUN of a socket filter with 14 byte input to determine whether
> > BPF_PROG_RUN is available or not. I'll fix this in cilium/ebpf, but I think this patch
> > needs more work since users may be doing the same thing in their code.
>
> Ooops, sorry about that.
>
> Instead of rejecting len=0 data, we might accept the packet but add
> some safe header? I think that should be more backwards compatible?
> Zhengchao, something you can look into?
Sorry for the delay. I'm busy testing the TC module recently. I'm very 
sorry for the user-space breakage.

The root cause of this problem is that eth_type_trans() is called when
the protocol type of the SKB is parsed. The len value of the SKB is
reduced to 0. If the user mode requires that the forwarding succeed, or
 if the MAC header is added again after the MAC header is subtracted, 
is this appropriate?

Zhengchao Shao
> > Thanks,
> > Lorenz
> >
> > 0: https://github.com/cilium/ebpf/pull/788