From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9D3E3C6FA90 for ; Sun, 25 Sep 2022 07:17:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230201AbiIYHRx (ORCPT ); Sun, 25 Sep 2022 03:17:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44624 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230056AbiIYHRw (ORCPT ); Sun, 25 Sep 2022 03:17:52 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EF36932EC0 for ; Sun, 25 Sep 2022 00:17:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1664090269; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=FnuW0+nquE7jeCs1wGd25t/HgD5sAtMc07QK9kih2sQ=; b=B97KTn2dpYAt61kIInCLOK/2Ro6Wst4uMijGFSzgHYRdcZYdeHN2Z3ugLtJoUKxafz8yNC sWsj/xIEwaV1yrv9Q1SsmiCxhVHRLyjrG7MDBtCipNp9CsQ1df0T63dAJdIXFk2HpFvimj SNz8dinnXFQVzc5AwMsgibAO84z47E8= Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-580-gDercgUCM5G5aQ4bGXoToQ-1; Sun, 25 Sep 2022 03:17:48 -0400 X-MC-Unique: gDercgUCM5G5aQ4bGXoToQ-1 Received: by mail-qt1-f199.google.com with SMTP id n16-20020ac85b50000000b0035ce9e26eb1so2686987qtw.8 for ; Sun, 25 Sep 2022 00:17:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date; bh=FnuW0+nquE7jeCs1wGd25t/HgD5sAtMc07QK9kih2sQ=; b=dtVxAWQ3A9qlMNM55eyHu7FGedJdwNOCxf3IM7tlr248kPsTz2PeJMSjX0bS+mFNzo nOJaeuaOoKqvHd8lLqS7RVRWrd+ej/s5Q4z2JBeSAbtHRBCcJFnavveo8d59U9uEgC0p Q77dzFX4CCzva35U0kn/eOdl+i3sLypUrsKUFxKu+/x+BxhPjyo8+iKfYDKQOPZTihlb MLDu30EBYf8Rzpd8VGliPDwfM1OvHIXXcs1ASsSdn6E7G2E4a+NZTEslFLuKg35MzXN+ W1XzjKRkiQHKlYqz3oDxyg4/W3N6RbKgZB+E1GKgpRctNFZOaKYBKqsolq3Fdvk5epSN spoA== X-Gm-Message-State: ACrzQf3ehZCQ07+zJ2p0HSO6Dl0UxBHb59D7JUhsOLa375/PoEWI9H/h dhyODN4XfbKGlVhKwG++C6eZv5PTJDNScmdYf0S6ke9ylxAkxB/9aCJg4ZEtsKKvmXS7f2XOJxG A2r0SjiCqZ+OTpBJ1 X-Received: by 2002:a05:620a:c8f:b0:6cb:e329:b5b9 with SMTP id q15-20020a05620a0c8f00b006cbe329b5b9mr10667164qki.95.1664090268091; Sun, 25 Sep 2022 00:17:48 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4u6YF4dJIrwAN1QRZGgvTOpwH6qKYsc23O//LxYiiudu83+P6fv+LpA21i63RBBqqlayo//g== X-Received: by 2002:a05:620a:c8f:b0:6cb:e329:b5b9 with SMTP id q15-20020a05620a0c8f00b006cbe329b5b9mr10667159qki.95.1664090267816; Sun, 25 Sep 2022 00:17:47 -0700 (PDT) Received: from gerbillo.redhat.com (146-241-97-96.dyn.eolo.it. [146.241.97.96]) by smtp.gmail.com with ESMTPSA id bp30-20020a05620a459e00b006c479acd82fsm10375465qkb.7.2022.09.25.00.17.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 25 Sep 2022 00:17:47 -0700 (PDT) Message-ID: Subject: Re: [PATCH v2 04/16] skbuff: Phase out ksize() fallback for frag_size From: Paolo Abeni To: Kees Cook , Vlastimil Babka Cc: "David S. Miller" , Eric Dumazet , Jakub Kicinski , netdev@vger.kernel.org, "Ruhl, Michael J" , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Greg Kroah-Hartman , Nick Desaulniers , Alex Elder , Josef Bacik , David Sterba , Sumit Semwal , Christian =?ISO-8859-1?Q?K=F6nig?= , Jesse Brandeburg , Daniel Micay , Yonghong Song , Marco Elver , Miguel Ojeda , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-btrfs@vger.kernel.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, linux-fsdevel@vger.kernel.org, intel-wired-lan@lists.osuosl.org, dev@openvswitch.org, x86@kernel.org, llvm@lists.linux.dev, linux-hardening@vger.kernel.org Date: Sun, 25 Sep 2022 09:17:40 +0200 In-Reply-To: <20220923202822.2667581-5-keescook@chromium.org> References: <20220923202822.2667581-1-keescook@chromium.org> <20220923202822.2667581-5-keescook@chromium.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.4 (3.42.4-2.fc35) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Fri, 2022-09-23 at 13:28 -0700, Kees Cook wrote: > All callers of APIs that allowed a 0-sized frag_size appear to be > passing actual size information already AFAICS, not yet: drivers/net/ethernet/qlogic/qed/qed_ll2.c: skb = build_skb(buffer->data, 0); // -> __build_skb(..., 0)  // -> __build_skb_around() drivers/net/ethernet/broadcom/bnx2.c: skb = build_skb(data, 0); I guess some more drivers have calls leading to  __build_skb_around(..., 0) there are several call path to checks... > , so this use of ksize() can > be removed. However, just in case there is something still depending > on this behavior, issue a WARN and fall back to as before to ksize() > which means we'll also potentially get KASAN warnings. > > Cc: "David S. Miller" > Cc: Eric Dumazet > Cc: Jakub Kicinski > Cc: Paolo Abeni > Cc: netdev@vger.kernel.org > Signed-off-by: Kees Cook > --- > net/core/skbuff.c | 18 ++++++++++-------- > 1 file changed, 10 insertions(+), 8 deletions(-) > > diff --git a/net/core/skbuff.c b/net/core/skbuff.c > index 0b30fbdbd0d0..84ca89c781cd 100644 > --- a/net/core/skbuff.c > +++ b/net/core/skbuff.c > @@ -195,7 +195,11 @@ static void __build_skb_around(struct sk_buff *skb, void *data, > unsigned int frag_size) > { > struct skb_shared_info *shinfo; > - unsigned int size = frag_size ? : ksize(data); > + unsigned int size = frag_size; > + > + /* All callers should be setting frag size now? */ > + if (WARN_ON_ONCE(size == 0)) > + size = ksize(data); At some point in the future, I guess we could even drop this check, right? Thanks! Paolo