| Message ID | 20220712120158.56325-1-shaozhengchao@huawei.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | BPF |
| Headers | show |
| Series | [bpf-next] bpf: Don't redirect packets with invalid pkt_len | expand |
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=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> > --- > 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? 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
On 7/12/22 6:58 PM, sdf@google.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=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> >> --- >> 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 >
-----邮件原件----- 发件人: Daniel Borkmann [mailto:daniel@iogearbox.net] 发送时间: 2022年7月13日 4:12 收件人: sdf@google.com; shaozhengchao <shaozhengchao@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; ast@kernel.org; andrii@kernel.org; martin.lau@linux.dev; song@kernel.org; yhs@fb.com; john.fastabend@gmail.com; kpsingh@kernel.org; weiyongjun (A) <weiyongjun1@huawei.com>; yuehaibing <yuehaibing@huawei.com> 主题: Re: [PATCH bpf-next] bpf: Don't redirect packets with invalid pkt_len On 7/12/22 6:58 PM, sdf@google.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@syzkaller.appspotmail.com >> Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.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
On 07/13, shaozhengchao wrote: > -----邮件原件----- > 发件人: Daniel Borkmann [mailto:daniel@iogearbox.net] > 发送时间: 2022年7月13日 4:12 > 收件人: sdf@google.com; shaozhengchao <shaozhengchao@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; ast@kernel.org; > andrii@kernel.org; martin.lau@linux.dev; song@kernel.org; yhs@fb.com; > john.fastabend@gmail.com; kpsingh@kernel.org; weiyongjun (A) > <weiyongjun1@huawei.com>; yuehaibing <yuehaibing@huawei.com> > 主题: Re: [PATCH bpf-next] bpf: Don't redirect packets with invalid > pkt_len > On 7/12/22 6:58 PM, sdf@google.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@syzkaller.appspotmail.com > >> Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.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. Not sure it belongs in convert___skb_to_skb, but checking somewhere before convert___skb_to_skb seems like a good way to go? > 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. I think the consensus so far that it's only bpf_prog_test_run that generates these types of packets, so let's start with fixing that.
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)) { kfree_skb(skb); return -ERANGE; }
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> --- net/core/filter.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)