From: Vasily Averin <vvs@virtuozzo.com>
To: "David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH] net: check skb partial checksum offset after trim
Date: Fri, 11 Dec 2020 18:37:33 +0300 [thread overview]
Message-ID: <1f8e9b9f-b319-9c03-d139-db57e30ce14f@virtuozzo.com> (raw)
In-Reply-To: <7080e8a3-6eaa-e9e1-afd8-b1eef38d1e89@virtuozzo.com>
Originally it was reported on Ubuntu 4.14 kernel,
then I've reproduced it on upstream 5.10-rc7.
If I'm right the problem is quite old and should
affect all maintained stable kernels too.
It seems for me the similar problem can happen in __skb_trim_rcsum().
Also I doubt that that skb_checksum_start_offset(skb) checks in
__skb_postpull_rcsum() and skb_csum_unnecessary() are correct,
becasue they do not guarantee that skb have correct CHECKSUM_PARTIAL.
Could somebody confirm it?
Thank you,
Vasily Averin
On 12/11/20 6:00 PM, Vasily Averin wrote:
> syzkaller reproduces BUG_ON in skb_checksum_help():
> tun creates skb with big partial checksum area and small ip packet inside,
> then ip_rcv() decreases skb size of below length of checksummed area,
> then checksum_tg() called via netfilter hook detects incorrect skb:
>
> offset = skb_checksum_start_offset(skb);
> BUG_ON(offset >= skb_headlen(skb));
>
> This patch drops CHEKSUM_PARTIAL mark when skb is trimmed below
> size of checksummed area.
> Link: https://syzkaller.appspot.com/bug?id=b419a5ca95062664fe1a60b764621eb4526e2cd0
> Reported-by: syzbot+7010af67ced6105e5ab6@syzkaller.appspotmail.com
> Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
> ---
> include/linux/skbuff.h | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index a828cf9..0a9545d 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -3419,9 +3419,18 @@ static inline void *skb_push_rcsum(struct sk_buff *skb, unsigned int len)
>
> static inline int pskb_trim_rcsum(struct sk_buff *skb, unsigned int len)
> {
> + int ret;
> +
> if (likely(len >= skb->len))
> return 0;
> - return pskb_trim_rcsum_slow(skb, len);
> + ret = pskb_trim_rcsum_slow(skb, len);
> + if (!ret && (skb->ip_summed == CHECKSUM_PARTIAL)) {
> + int offset = skb_checksum_start_offset(skb) + skb->csum_offset;
> +
> + if (offset + sizeof(__sum16) > skb_headlen(skb))
> + skb->ip_summed = CHECKSUM_NONE;
> + }
> + return ret;
> }
>
> static inline int __skb_trim_rcsum(struct sk_buff *skb, unsigned int len)
>
next prev parent reply other threads:[~2020-12-11 16:34 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-11 15:00 [PATCH] net: check skb partial checksum offset after trim Vasily Averin
2020-12-11 15:37 ` Vasily Averin [this message]
2020-12-12 8:29 ` Vasily Averin
2020-12-12 23:49 ` Willem de Bruijn
2020-12-13 19:37 ` Vasily Averin
2020-12-14 1:59 ` Willem de Bruijn
2020-12-14 19:07 ` [PATCH v2] net: drop bogus skb with CHECKSUM_PARTIAL and offset beyond end of trimmed packet Vasily Averin
2020-12-14 20:59 ` Willem de Bruijn
2020-12-15 3:10 ` patchwork-bot+netdevbpf
2020-12-14 20:54 ` [PATCH] net: check skb partial checksum offset after trim Jakub Kicinski
2020-12-14 21:07 ` Willem de Bruijn
2020-12-15 5:42 ` Vasily Averin
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=1f8e9b9f-b319-9c03-d139-db57e30ce14f@virtuozzo.com \
--to=vvs@virtuozzo.com \
--cc=davem@davemloft.net \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).