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: [email protected]
> Signed-off-by: Zhengchao Shao <[email protected]>
> ---
> 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, [email protected] 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: [email protected]
>> Signed-off-by: Zhengchao Shao <[email protected]>
>> ---
>> 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
>