From: Martin KaFai Lau <martin.lau@linux.dev>
To: Zhengchao Shao <shaozhengchao@huawei.com>
Cc: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
song@kernel.org, yhs@fb.com, john.fastabend@gmail.com,
kpsingh@kernel.org, sdf@google.com, bigeasy@linutronix.de,
imagedong@tencent.com, petrm@nvidia.com, arnd@arndb.de,
dsahern@kernel.org, talalahmad@google.com, keescook@chromium.org,
haoluo@google.com, jolsa@kernel.org, weiyongjun1@huawei.com,
yuehaibing@huawei.com, bpf@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, hawk@kernel.org
Subject: Re: [PATCH v4,bpf-next] bpf: Don't redirect packets with invalid pkt_len
Date: Thu, 3 Nov 2022 14:07:44 -0700 [thread overview]
Message-ID: <f0bb3cd6-6986-6ca1-aa40-7a10302c8586@linux.dev> (raw)
In-Reply-To: <20220715115559.139691-1-shaozhengchao@huawei.com>
On 7/15/22 4:55 AM, Zhengchao Shao wrote:
> Syzbot found an issue [1]: fq_codel_drop() try to drop a flow whitout any
> skbs, that is, the flow->head is null.
> The root cause, as the [2] says, is because that bpf_prog_test_run_skb()
> run a bpf prog which redirects empty skbs.
> So we should determine whether the length of the packet modified by bpf
> prog or others like bpf_prog_test is valid before forwarding it directly.
>
> LINK: [1] https://syzkaller.appspot.com/bug?id=0b84da80c2917757915afa89f7738a9d16ec96c5
> LINK: [2] https://www.spinics.net/lists/netdev/msg777503.html
>
> Reported-by: syzbot+7a12909485b94426aceb@syzkaller.appspotmail.com
> Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
> ---
> v3: modify debug print
> v2: need move checking to convert___skb_to_skb and add debug info
> v1: should not check len in fast path
>
> include/linux/skbuff.h | 8 ++++++++
> net/bpf/test_run.c | 3 +++
> net/core/dev.c | 1 +
> 3 files changed, 12 insertions(+)
>
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index f6a27ab19202..82e8368ba6e6 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -2459,6 +2459,14 @@ static inline void skb_set_tail_pointer(struct sk_buff *skb, const int offset)
>
> #endif /* NET_SKBUFF_DATA_USES_OFFSET */
>
> +static inline void skb_assert_len(struct sk_buff *skb)
> +{
> +#ifdef CONFIG_DEBUG_NET
> + if (WARN_ONCE(!skb->len, "%s\n", __func__))
> + DO_ONCE_LITE(skb_dump, KERN_ERR, skb, false);
> +#endif /* CONFIG_DEBUG_NET */
> +}
> +
> /*
> * Add data to an sk_buff
> */
> diff --git a/net/bpf/test_run.c b/net/bpf/test_run.c
> index 2ca96acbc50a..dc9dc0bedca0 100644
> --- a/net/bpf/test_run.c
> +++ b/net/bpf/test_run.c
> @@ -955,6 +955,9 @@ static int convert___skb_to_skb(struct sk_buff *skb, struct __sk_buff *__skb)
> {
> struct qdisc_skb_cb *cb = (struct qdisc_skb_cb *)skb->cb;
>
> + if (!skb->len)
> + return -EINVAL;
From another recent report [0], I don't think this change is fixing the report
from syzbot. It probably makes sense to revert this patch.
afaict, This '!skb->len' test is done after
if (is_l2)
__skb_push(skb, hh_len);
Hence, skb->len is not zero in convert___skb_to_skb(). The proper place to test
skb->len is before __skb_push() to ensure there is some network header after the
mac or may as well ensure "data_size_in > ETH_HLEN" at the beginning.
The fix in [0] is applied. If it turns out there are other cases caused by the
skb generated by test_run that needs extra fixes in bpf_redirect_*, it needs to
revisit an earlier !skb->len check mentioned above and the existing test cases
outside of test_progs would have to adjust accordingly.
[0]: https://lore.kernel.org/bpf/20221027225537.353077-1-sdf@google.com/
> +
> if (!__skb)
> return 0;
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index d588fd0a54ce..716df64fcfa5 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -4168,6 +4168,7 @@ int __dev_queue_xmit(struct sk_buff *skb, struct net_device *sb_dev)
> bool again = false;
>
> skb_reset_mac_header(skb);
> + skb_assert_len(skb);
>
> if (unlikely(skb_shinfo(skb)->tx_flags & SKBTX_SCHED_TSTAMP))
> __skb_tstamp_tx(skb, NULL, NULL, skb->sk, SCM_TSTAMP_SCHED);
next prev parent reply other threads:[~2022-11-03 21:10 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-15 11:55 [PATCH v4,bpf-next] bpf: Don't redirect packets with invalid pkt_len Zhengchao Shao
2022-07-15 23:30 ` Stanislav Fomichev
2022-07-19 17:00 ` patchwork-bot+netdevbpf
2022-09-14 11:19 ` Lorenz Bauer
2022-09-17 15:46 ` Stanislav Fomichev
2022-09-19 10:55 ` shaozhengchao
2022-09-20 14:42 ` Lorenz Bauer
2022-09-21 8:48 ` shaozhengchao
2022-09-21 20:59 ` Stanislav Fomichev
2022-10-13 9:36 ` Lorenz Bauer
2022-10-13 10:44 ` shaozhengchao
2022-10-14 16:29 ` Lorenz Bauer
2022-10-14 16:55 ` sdf
2022-10-15 2:36 ` shaozhengchao
2022-11-03 21:07 ` Martin KaFai Lau [this message]
2022-11-03 21:36 ` Stanislav Fomichev
2022-11-03 22:42 ` Martin KaFai Lau
2022-11-03 22:58 ` Stanislav Fomichev
2022-11-09 21:43 ` Stanislav Fomichev
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=f0bb3cd6-6986-6ca1-aa40-7a10302c8586@linux.dev \
--to=martin.lau@linux.dev \
--cc=andrii@kernel.org \
--cc=arnd@arndb.de \
--cc=ast@kernel.org \
--cc=bigeasy@linutronix.de \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=haoluo@google.com \
--cc=hawk@kernel.org \
--cc=imagedong@tencent.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=keescook@chromium.org \
--cc=kpsingh@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=petrm@nvidia.com \
--cc=sdf@google.com \
--cc=shaozhengchao@huawei.com \
--cc=song@kernel.org \
--cc=talalahmad@google.com \
--cc=weiyongjun1@huawei.com \
--cc=yhs@fb.com \
--cc=yuehaibing@huawei.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.