From: Daniel Borkmann <daniel@iogearbox.net>
To: Eric Dumazet <edumazet@google.com>,
Alexei Starovoitov <alexei.starovoitov@gmail.com>,
Guillaume Nault <gnault@redhat.com>
Cc: patchwork-bot+netdevbpf@kernel.org,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Alexei Starovoitov <ast@kernel.org>,
Martin KaFai Lau <martin.lau@linux.dev>,
Andrii Nakryiko <andrii@kernel.org>,
Network Development <netdev@vger.kernel.org>,
bpf <bpf@vger.kernel.org>, Eric Dumazet <eric.dumazet@gmail.com>,
syzbot+9e27778c0edc62cb97d8@syzkaller.appspotmail.com,
Stanislav Fomichev <sdf@google.com>,
Willem de Bruijn <willemb@google.com>
Subject: Re: [PATCH net] bpf: Don't redirect too small packets
Date: Mon, 25 Mar 2024 16:47:13 +0100 [thread overview]
Message-ID: <69bb87ad-bd0a-7cdc-7e01-e8a403c6689f@iogearbox.net> (raw)
In-Reply-To: <CANn89iLSOeFGNogYMHbeLRC5kOwwArMz3d5_2hZmBn6fibyUhw@mail.gmail.com>
On 3/25/24 2:33 PM, Eric Dumazet wrote:
> On Sat, Mar 23, 2024 at 4:02 AM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
>> On Fri, Mar 22, 2024 at 7:10 AM <patchwork-bot+netdevbpf@kernel.org> wrote:
>>>
>>> Hello:
>>>
>>> This patch was applied to bpf/bpf.git (master)
>>> by Daniel Borkmann <daniel@iogearbox.net>:
>>>
>>> On Fri, 22 Mar 2024 12:24:07 +0000 you wrote:
>>>> Some drivers ndo_start_xmit() expect a minimal size, as shown
>>>> by various syzbot reports [1].
>>>>
>>>> Willem added in commit 217e6fa24ce2 ("net: introduce device min_header_len")
>>>> the missing attribute that can be used by upper layers.
>>>>
>>>> We need to use it in __bpf_redirect_common().
>>
>> This patch broke empty_skb test:
>> $ test_progs -t empty_skb
>>
>> test_empty_skb:FAIL:ret: veth ETH_HLEN+1 packet ingress
>> [redirect_ingress] unexpected ret: veth ETH_HLEN+1 packet ingress
>> [redirect_ingress]: actual -34 != expected 0
>> test_empty_skb:PASS:err: veth ETH_HLEN+1 packet ingress [redirect_egress] 0 nsec
>> test_empty_skb:FAIL:ret: veth ETH_HLEN+1 packet ingress
>> [redirect_egress] unexpected ret: veth ETH_HLEN+1 packet ingress
>> [redirect_egress]: actual -34 != expected 1
>>
>> And looking at the test I think it's not a test issue.
>> This check
>> if (unlikely(skb->len < dev->min_header_len))
>> is rejecting more than it should.
>>
>> So I reverted this patch for now.
>
> OK, it seems I missed __bpf_rx_skb() vs __bpf_tx_skb(), but even if I
> move my sanity test in __bpf_tx_skb(),
> the bpf test program still fails, I am suspecting the test needs to be adjusted.
Let me take a look, I do think so too that we'd need to adjust the test.
I'll see to have a patch for the latter so that we can reapply the fix
as-is along with it given it's correct.
> diff --git a/net/core/filter.c b/net/core/filter.c
> index 745697c08acb3a74721d26ee93389efa81e973a0..e9c0e2087a08f1d8afd2c3e8e7871ddc9231b76d
> 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -2128,6 +2128,12 @@ static inline int __bpf_tx_skb(struct
> net_device *dev, struct sk_buff *skb)
> return -ENETDOWN;
> }
>
> + if (unlikely(skb->len < dev->min_header_len)) {
> + pr_err_once("__bpf_tx_skb skb->len=%u <
> dev(%s)->min_header_len(%u)\n", skb->len, dev->name,
> dev->min_header_len);
> + DO_ONCE_LITE(skb_dump, KERN_ERR, skb, false);
> + kfree_skb(skb);
> + return -ERANGE;
> + } // Note: this is before we change skb->dev
> skb->dev = dev;
> skb_set_redirected_noclear(skb, skb_at_tc_ingress(skb));
> skb_clear_tstamp(skb);
>
>
> -->
>
>
> test_empty_skb:FAIL:ret: veth ETH_HLEN+1 packet ingress
> [redirect_egress] unexpected ret: veth ETH_HLEN+1 packet ingress
> [redirect_egress]: actual -34 != expected 1
>
> [ 58.382051] __bpf_tx_skb skb->len=1 < dev(veth0)->min_header_len(14)
> [ 58.382778] skb len=1 headroom=78 headlen=1 tailroom=113
> mac=(64,14) net=(78,-1) trans=-1
> shinfo(txflags=0 nr_frags=0 gso(size=0 type=0 segs=0))
> csum(0x0 ip_summed=0 complete_sw=0 valid=0 level=0)
> hash(0x0 sw=0 l4=0) proto=0x7f00 pkttype=0 iif=0
>
> Note that veth driver is one of the few 'Ethernet' drivers that make
> sure to get at least 14 bytes in the skb at ndo_start_xmit()
> after commit 726e2c5929de841fdcef4e2bf995680688ae1b87 ("veth: Ensure
> eth header is in skb's linear part")
>
> BTW this last patch (changing veth) should have been done generically
> from act_mirred
>
> (We do not want to patch ~400 ethernet drivers in the tree)
>
next prev parent reply other threads:[~2024-03-25 15:47 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-22 12:24 [PATCH net] bpf: Don't redirect too small packets Eric Dumazet
2024-03-22 14:10 ` patchwork-bot+netdevbpf
2024-03-23 3:01 ` Alexei Starovoitov
2024-03-25 13:33 ` Eric Dumazet
2024-03-25 15:47 ` Daniel Borkmann [this message]
2024-03-25 15:56 ` Alexei Starovoitov
2024-03-25 16:28 ` Stanislav Fomichev
2024-03-26 12:46 ` Daniel Borkmann
2024-03-26 13:37 ` Eric Dumazet
2024-03-26 13:38 ` Eric Dumazet
2024-03-26 17:57 ` Daniel Borkmann
2024-03-26 18:08 ` Eric Dumazet
2024-09-22 17:39 ` Eric Dumazet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=69bb87ad-bd0a-7cdc-7e01-e8a403c6689f@iogearbox.net \
--to=daniel@iogearbox.net \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=eric.dumazet@gmail.com \
--cc=gnault@redhat.com \
--cc=kuba@kernel.org \
--cc=martin.lau@linux.dev \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=patchwork-bot+netdevbpf@kernel.org \
--cc=sdf@google.com \
--cc=syzbot+9e27778c0edc62cb97d8@syzkaller.appspotmail.com \
--cc=willemb@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox