linux-kernel - Re: [PATCH bpf-next] bpf: Don't redirect packets with invalid pkt

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <Ys2oPzt7Yn1oMou8@google.com>
Date:   Tue, 12 Jul 2022 09:58:39 -0700
From:   sdf@...gle.com
To:     Zhengchao Shao <shaozhengchao@...wei.com>
Cc:     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, daniel@...earbox.net,
        andrii@...nel.org, martin.lau@...ux.dev, song@...nel.org,
        yhs@...com, john.fastabend@...il.com, kpsingh@...nel.org,
        weiyongjun1@...wei.com, yuehaibing@...wei.com
Subject: Re: [PATCH bpf-next] bpf: Don't redirect packets with invalid pkt_len

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@...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?

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