[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d7f22715be8d477cbc3e6e545c219048@huawei.com>
Date: Wed, 13 Jul 2022 12:53:36 +0000
From: shaozhengchao <shaozhengchao@...wei.com>
To: Daniel Borkmann <daniel@...earbox.net>,
"sdf@...gle.com" <sdf@...gle.com>
CC: "bpf@...r.kernel.org" <bpf@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"davem@...emloft.net" <davem@...emloft.net>,
"edumazet@...gle.com" <edumazet@...gle.com>,
"kuba@...nel.org" <kuba@...nel.org>,
"pabeni@...hat.com" <pabeni@...hat.com>,
"hawk@...nel.org" <hawk@...nel.org>,
"ast@...nel.org" <ast@...nel.org>,
"andrii@...nel.org" <andrii@...nel.org>,
"martin.lau@...ux.dev" <martin.lau@...ux.dev>,
"song@...nel.org" <song@...nel.org>, "yhs@...com" <yhs@...com>,
"john.fastabend@...il.com" <john.fastabend@...il.com>,
"kpsingh@...nel.org" <kpsingh@...nel.org>,
"weiyongjun (A)" <weiyongjun1@...wei.com>,
yuehaibing <yuehaibing@...wei.com>
Subject: 答复: [PATCH bpf-next] bpf: Don't redirect packets with invalid pkt_len
-----邮件原件-----
发件人: Daniel Borkmann [mailto:daniel@...earbox.net]
发送时间: 2022年7月13日 4:12
收件人: sdf@...gle.com; shaozhengchao <shaozhengchao@...wei.com>
抄送: bpf@...r.kernel.org; netdev@...r.kernel.org; linux-kernel@...r.kernel.org; davem@...emloft.net; edumazet@...gle.com; kuba@...nel.org; pabeni@...hat.com; hawk@...nel.org; ast@...nel.org; andrii@...nel.org; martin.lau@...ux.dev; song@...nel.org; yhs@...com; john.fastabend@...il.com; kpsingh@...nel.org; weiyongjun (A) <weiyongjun1@...wei.com>; yuehaibing <yuehaibing@...wei.com>
主题: Re: [PATCH bpf-next] bpf: Don't redirect packets with invalid pkt_len
On 7/12/22 6:58 PM, sdf@...gle.com wrote:
> On 07/12, 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=0b84da80c2917757915afa89f7738a9d
>> 16ec96c5
>> LINK: [2] https://www.spinics.net/lists/netdev/msg777503.html
>
>> Reported-by: syzbot+7a12909485b94426aceb@...kaller.appspotmail.com
>> Signed-off-by: Zhengchao Shao <shaozhengchao@...wei.com>
>> ---
>> net/core/filter.c | 9 ++++++++-
>> 1 file changed, 8 insertions(+), 1 deletion(-)
>
>> diff --git a/net/core/filter.c b/net/core/filter.c index
>> 4ef77ec5255e..27801b314960 100644
>> --- a/net/core/filter.c
>> +++ b/net/core/filter.c
>> @@ -2122,6 +2122,11 @@ static int __bpf_redirect_no_mac(struct
>> sk_buff *skb, struct net_device *dev,
>> {
>> unsigned int mlen = skb_network_offset(skb);
>
>> + if (unlikely(skb->len == 0)) {
>> + kfree_skb(skb);
>> + return -EINVAL;
>> + }
>> +
>> if (mlen) {
>> __skb_pull(skb, mlen);
>
>> @@ -2143,7 +2148,9 @@ static int __bpf_redirect_common(struct sk_buff
>> *skb, struct net_device *dev,
>> u32 flags)
>> {
>> /* Verify that a link layer header is carried */
>> - if (unlikely(skb->mac_header >= skb->network_header)) {
>> + if (unlikely(skb->mac_header >= skb->network_header) ||
>> + (min_t(u32, skb_mac_header_len(skb), skb->len) <
>> + (u32)dev->min_header_len)) {
>
> Why check skb->len != 0 above but skb->len < dev->min_header_len here?
> I guess it doesn't make sense in __bpf_redirect_no_mac because we know
> that mac is empty, but why do we care in __bpf_redirect_common?
> Why not put this check in the common __bpf_redirect?
>
> Also, it's still not clear to me whether we should bake it into the
> core stack vs having some special checks from test_prog_run only. I'm
> assuming the issue is that we can construct illegal skbs with that
> test_prog_run interface, so maybe start by fixing that?
Agree, ideally we can prevent it right at the source rather than adding more tests into the fast-path.
> Did you have a chance to look at the reproducer more closely? What
> exactly is it doing?
>
>> kfree_skb(skb);
>> return -ERANGE;
>> }
>> --
>> 2.17.1
>
Hi Daniel and sdf:
Thank you for your reply. I read the poc code carefully, and I think the current call stack is like:
sys_bpf(BPF_PROG_TEST_RUN, &attr, sizeof(attr)) -> bpf_prog_test_run->bpf_prog_test_run_skb.
In function bpf_prog_test_run_skb, procedure will use build_skb to generate a new skb. Poc code pass
a 14Byte packet for direct. First ,skb->len = 14, but after trans eth type, the len = 0; but is_l2 is false,
so len=0 when run bpf_test_run. Is it possible to add check in convert___skb_to_skb? When skb->len=0,
we drop the packet.
But, if some other paths call bpf redirect with skb->len=0, this is not effective, such as some driver call redirect fuction.
I don't know if I'm thinking right.
Thank you.
Zhengchao Shao
Powered by blists - more mailing lists