Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp3992291pxb; Mon, 1 Feb 2021 09:37:03 -0800 (PST) X-Google-Smtp-Source: ABdhPJyAYIYqHJQ0R9OjXl2ai3/luTSQgwwyKkpl3kFVG1Q7BZTUMFS1K++TucXt9rQI40QpRn2I X-Received: by 2002:aa7:d4d7:: with SMTP id t23mr19694215edr.321.1612201023482; Mon, 01 Feb 2021 09:37:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612201023; cv=none; d=google.com; s=arc-20160816; b=HE0XpojfDbK0cMRSyyR+1yZkGYU8KuPHQzagQAlyeRKRwK1dMmOMn5YCCtLBMsNKwI +B5uSYd5IDDontpOJirIvV72CgdM/F46JVimwBoTrx+t7ALU5Q456+6GmilZ85M4vcGf 3GFJCXpnTd5rwR1yKKmg0AtxCvA5zLYE+qc/bAsgZbNmXrY8HPQ0p9dLPqk3xDvA4BLq TxPTQXotaUnSg9Tm1tF+075lO5IffXLWOPSuLyo+i6YAWhARA1Y1Ev8nobH2xnVKkSNN tulKqKHyqutcrlMcgZVQUX6yOVyVKfv6upJOEPv+hcVfw9MUj0dZ9Oo7VdLgxrt49Z9t EcLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=oe4wUnUrEXeJigbdmJ1Zo8HkG5rVFt/oiu13Xp4cGG0=; b=q/q7Ipyq3e1WoGwFGTuQoGDWNCtMoFu9Cj8mK4ygzyLbGOX2yGIlq0IrPfJrZ8puE/ L8ySVDcZdHlK57B/70Qsig36OzsJXtQv8Y4axo47GGo7znk2xeBzgLAvteC/KnxN2h/7 KFN27B/jDz5mpYitjtqrAvwhO0R38IJzlqjUkXt1f7NZMPHGp9/ysLKt60n5PxCy8ckA Wph6JPZhDyJbfFIWAYX7OPcO0aRHggkrAPQkqTGW6UhUsW/IzYVBVgornZbTub7PVDAC WM1Ha+Sw+Szw0csIC7Jyl3LKgmPDx3r7cqa7FS6zfYjDQD27FOoXKnfi5ELNi8DsHhlm Epzg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=PTLhm003; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e17si10912803edz.241.2021.02.01.09.36.36; Mon, 01 Feb 2021 09:37:03 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=PTLhm003; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231346AbhBARfW (ORCPT + 99 others); Mon, 1 Feb 2021 12:35:22 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40414 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232023AbhBARet (ORCPT ); Mon, 1 Feb 2021 12:34:49 -0500 Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AE689C061573 for ; Mon, 1 Feb 2021 09:34:09 -0800 (PST) Received: by mail-ot1-x329.google.com with SMTP id 36so17102074otp.2 for ; Mon, 01 Feb 2021 09:34:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oe4wUnUrEXeJigbdmJ1Zo8HkG5rVFt/oiu13Xp4cGG0=; b=PTLhm003t2nT8U2zXIdgG6IheLGILeyuclP58pkLvAqh3W4k+xXQUoIsFumj+Iab2b 1XyGBk85FvrAyfi/9KIot6WYeUN6eeFS/AjEcQjRV6YRYrQS7+P7+hTmHN+RYZNchuqA 5w4nouIvHuGAOFErY81K9U7TgzKlWUB8GXfZ2hzXTj8abMexjbF1kBNLixpSlwfRCf+H WwpJ6dZOmYpDtS3YML2ajWUiNBjsrXi3vVrMNx0njQT34x+Tv98HK//m30SfaahGpVso YBEFsUeB63iNk/TPJiSJrSThfxqCgMUTCWvV2fKz876Ss8YJiueCakpXKIYxczOF6iy7 YgRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oe4wUnUrEXeJigbdmJ1Zo8HkG5rVFt/oiu13Xp4cGG0=; b=lpMDBWi5a9ImSa7wOiRVSgsqUS7B7yFGiRhdR+/D7mwBoh/UgbnXTe9i2GrkHj7wao +ZN+0u6KSJ9uELnzJ3gdxOmyKUFIvykZq9ACB6XNpGPDVe4GFr8Iy1GZwLjktJhFv77k +zPuPZYp7xsTKc0HFUAG3OOFpiW3P/FLDBIkyAI2HTBfccKURtqN0NbiHLglqs5hd0Qv tpKdYmXysi0vX+QsQDdIG6qo6+4HGos8dTijm1IOI/SPr23u3r0SJal0e/uQM9QrcSGn vtOXaSsrwPK+4DYUa4i4eNpwZsYmvEjDMdfV9sNX3SOszwossgxf3/HmBC7/swAXRRA6 hQXQ== X-Gm-Message-State: AOAM531frC+x0dgO3Dfo5QOqkN9we/sjhHo2SYDeksoXuYdiqii6GzOz PaKtErRE2e2f5XjTdNZ1vatkKW+y0lZVicpTCCpJFUxulV8= X-Received: by 2002:a9d:3bb7:: with SMTP id k52mr13016105otc.251.1612200848825; Mon, 01 Feb 2021 09:34:08 -0800 (PST) MIME-Version: 1.0 References: <20210201160420.2826895-1-elver@google.com> In-Reply-To: From: Marco Elver Date: Mon, 1 Feb 2021 18:33:56 +0100 Message-ID: Subject: Re: [PATCH net-next] net: fix up truesize of cloned skb in skb_prepare_for_shift() To: Christoph Paasch Cc: LKML , kasan-dev , David Miller , Jakub Kicinski , Jonathan Lemon , Willem de Bruijn , linmiaohe@huawei.com, gnault@redhat.com, dseok.yi@samsung.com, kyk.segfault@gmail.com, Al Viro , netdev , Alexander Potapenko , syzbot , Eric Dumazet Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 1 Feb 2021 at 17:50, Christoph Paasch wrote: > On Mon, Feb 1, 2021 at 8:09 AM Marco Elver wrote: > > > > Avoid the assumption that ksize(kmalloc(S)) == ksize(kmalloc(S)): when > > cloning an skb, save and restore truesize after pskb_expand_head(). This > > can occur if the allocator decides to service an allocation of the same > > size differently (e.g. use a different size class, or pass the > > allocation on to KFENCE). > > > > Because truesize is used for bookkeeping (such as sk_wmem_queued), a > > modified truesize of a cloned skb may result in corrupt bookkeeping and > > relevant warnings (such as in sk_stream_kill_queues()). > > > > Link: https://lkml.kernel.org/r/X9JR/J6dMMOy1obu@elver.google.com > > Reported-by: syzbot+7b99aafdcc2eedea6178@syzkaller.appspotmail.com > > Suggested-by: Eric Dumazet > > Signed-off-by: Marco Elver > > --- > > net/core/skbuff.c | 14 +++++++++++++- > > 1 file changed, 13 insertions(+), 1 deletion(-) > > > > diff --git a/net/core/skbuff.c b/net/core/skbuff.c > > index 2af12f7e170c..3787093239f5 100644 > > --- a/net/core/skbuff.c > > +++ b/net/core/skbuff.c > > @@ -3289,7 +3289,19 @@ EXPORT_SYMBOL(skb_split); > > */ > > static int skb_prepare_for_shift(struct sk_buff *skb) > > { > > - return skb_cloned(skb) && pskb_expand_head(skb, 0, 0, GFP_ATOMIC); > > + int ret = 0; > > + > > + if (skb_cloned(skb)) { > > + /* Save and restore truesize: pskb_expand_head() may reallocate > > + * memory where ksize(kmalloc(S)) != ksize(kmalloc(S)), but we > > + * cannot change truesize at this point. > > + */ > > + unsigned int save_truesize = skb->truesize; > > + > > + ret = pskb_expand_head(skb, 0, 0, GFP_ATOMIC); > > + skb->truesize = save_truesize; > > + } > > + return ret; > > just a few days ago we found out that this also fixes a syzkaller > issue on MPTCP (https://github.com/multipath-tcp/mptcp_net-next/issues/136). > I confirmed that this patch fixes the issue for us as well: > > Tested-by: Christoph Paasch That's interesting, because according to your config you did not have KFENCE enabled. Although it's hard to say what exactly caused the truesize mismatch in your case, because it clearly can't be KFENCE that caused ksize(kmalloc(S))!=ksize(kmalloc(S)) for you. Thanks, -- Marco