From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793826893; b=DQfbRCZUZrH6O07xzavOh8CCOSk7fuuvQ7Nf4OKKzSzJE5XOFISoDzjDgCWV+KJzs8vG n8GV1LwFpgXx/8iatVvQc6m3y8jpSZfBnkVFGznzc9cUUGtMoYiy1UtIfdh7tY5ApSLnd Qyrkls/cxsyKdEgb735klE3aDHEEJFtkpON3+GbLsyidZuvQpIr5zQFzTixCnAEnfM+zF UL920RAg3enGdTkucRAQMHCw+cmXrqVtIS5J1VxzCzzCvy/Y7wkIpAlL4hiw84JdJN60u tBkdTh4SWNSGyx3OFlPsuuCVstYI9PFJdstO5X7mQwpuXmg5U0aqmH+bljO9+BhWaNw== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793826893; h=Received:DKIM-Signature:Message-ID:From:Subject:Reply-To:To:Cc: In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date; bh=wMYCt5EP/sNWDxIUvBX8we5zMZEdPqHevTqaZp/nA6U=; b=xp+v4EEeR8hD9Xrg+1ZHQkD77rLzpgr7O/IWs6G21q0wSPyq320Fjwp4lJUz6QdyOmYG iqzQ21ShwKq5ZM91i/5HNp7DDYKFTWiyDvmX9eg27Q11ft0Sy1xEQxgY0QXgAFEqS0o3O YTJ0C6cyUoKH8rj1LqOE1vWPca8nOwbHyAgFzbMP7CGBilPbPeOG7v5iEBVh4xjwiB372 QX0AO0rUo71xRR5RCKGbVfjip3QRyFce7auBtMrd9IBva07FnFXFYiCX3h+1A4UI7AfAH yWAl1BIdtB2n0qhPcsSd5lcaXCPqveoxgYOGo6VsAdkTviR7DeNkVJGI1PNliWKl2iQ== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=EupUpYNb; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E0BF2607075B; Wed, 4 Nov 2026 21:14:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=EupUpYNb Received: by smtp.kernel.org (Postfix) with ESMTPSA id A46161F0093A; Wed, 4 Nov 2026 21:14:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1793826892; bh=wMYCt5EP/sNWDxIUvBX8we5zMZEdPqHevTqaZp/nA6U=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=EupUpYNbxsz7bxH1Xzhu1FdX+NjLRR6kk4e4PfJE7IMhtjK7/HWHEMKGK108XFPhS mBwSFyjkd183mb6RqzkERIBKWvlcjGSx0uKON9JOdu0eq4hUKnCXRz669Laqlw4yVd W7nSUjz3LeWEHdPY5DLD4UanqsN3qrhBUv32Fp1qwlEKJXjg59aq/U94RtHRFKTg7D imBGe3ru67Ls+x0axIKynDMFis1BtlyEqG0fRMtPLDtffXBT4cUsviW7QYExBRkbOy s5kkuE5RxZcZs+9vddUbBdS88QI7/R2ST4LsqyQjyK1XhBYoWoOIHd6qVdMfevYpSM CIQJcp9jsMIZA== Message-ID: From: sashiko-bot@kernel.org Subject: Re: [PATCH net-next v1 2/5] net: skbuff: refcount spliced page_pool frags via skb_pipe_buf_ops Reply-To: sashiko-reviews@lists.linux.dev To: "Mina Almasry" , virtualization@lists.linux.dev, linux-mm@kvack.org, bpf@vger.kernel.org, bcm-kernel-feedback-list@broadcom.com, imx@lists.linux.dev, linux-rdma@vger.kernel.org, linux-hyperv@vger.kernel.org Cc: "David S. Miller" , "Eric Dumazet" , "Jakub Kicinski" , "Paolo Abeni" , "Simon Horman" , "Steffen Klassert" , "Herbert Xu" , "Willem de Bruijn" , "Stanislav Fomichev" , "Pavel Begunkov" , "Bobby Eshleman" , "Andrew Lunn" , "Michael S. Tsirkin" , "Jason Wang" , =?utf-8?b?RXVnZW5pbyBQw6lyZXo=?= , "Xuan Zhuo" , "Andrew Morton" , "David Hildenbrand" , "Lorenzo Stoakes" , "Liam R. Howlett" , "Vlastimil Babka" , "Mike Rapoport" , "Suren Baghdasaryan" , "Michal Hocko" , "Jesper Dangaard Brouer" , "Ilias Apalodimas" , "Alexei Starovoitov" , "Daniel Borkmann" , "John Fastabend" , "Sabrina Dubroca" , "Johannes Berg" , "Byungchul Park" , "Jonathan Corbet" , "Shuah Khan" , "Randy Dunlap" , "Lorenzo Bianconi" , "Wen Gu" , "Philo Lu" , "Justin Chen" , "Florian Fainelli" , "Vikas Gupta" , "Michael Chan" , "Pavan Chebbi" , "Doug Berger" , "Nicolai Buchwitz" , "Satish Kharat" , "Wei Fang" , "Frank Li" , "Shenwei Wang" , "Joshua Washington" , "Harshitha Ramamurthy" , "Jijie Shao" , "Jian Shen" , "Fan Gong" , "Tony Nguyen" , "Przemek Kitszel" , "Marcin Wojtas" , "Russell King" , "Sunil Goutham" , "Geetha sowjanya" , "Ratheesh Kannoth" , "Subbaraya Sundeep" , "Bharat Bhushan" , "Felix Fietkau" , "Matthias Brugger" , "AngeloGioacchino Del Regno" , "Tariq Toukan" , "Saeed Mahameed" , "Mark Bloch" , "Leon Romanovsky" , "Ido Schimmel" , "Petr Machata" , "Horatiu Vultur" , UNGLinuxDriver@microchip.com, "Daniel Machon" , "Steen Hegelund" , "Haiyang Zhang" , "Wei Liu" , "Dexuan Cui" , "Yibo Dong" , "Brett Creeley" , "Justin Lai" , "Larry Chiu" , =?utf-8?b?TmlrbGFzIFPDtmRlcmx1bmQ=?= , "Paul Barker" , "Masahisa Kojima" , "Maxime Chevallier" , "Maxime Coquelin" , "Alexandre Torgue" , "FUJITA Tomonori" , "Siddharth Vadapalli" , "Roger Quadros" , "MD Danish Anwar" , "Jiawen Wu" , "Mengyuan Lou" , "Ronak Doshi" , "Ryder Lee" , "Shayne Chen" , "Sean Wang" , "Juergen Gross" , "Stefano Stabellini" , "Oleksandr Tyshchenko" , "Jordan Rhee" , "Ankit Garg" , "Tim Hostetler" , "Erni Sri Satya Vennela" , "Eric Joyner" , "Mohammad Heib" , "Prabu Thayalan" , "Chintan Vankar" , "Nora Schiffer" , "Alexander Sverdlin" , "Kevin Hao" , "Karl Mehltretter" , "Aleksandr Loktionov" , "Meghana Malladi" , "Jacob Keller" , "StanleyYP Wang" , Frank.Li@kernel.org, wsa+renesas@sang-engineering.com In-Reply-To: <20261103211424.127627-3-almasrymina@google.com> References: <20261103211424.127627-1-almasrymina@google.com> <20261103211424.127627-3-almasrymina@google.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Wed, 04 Nov 2026 21:14:45 +0000 X-Mailing-List: bpf@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list Thank you for your contribution! Sashiko AI review found 1 potential issue(= s) to consider: - [High] net: skbuff: missing refcount overflow check in skb_pipe_buf_get() -- commit 9c79ad1ae20fce07ba4bd771a989ba25467dc207 Author: Mina Almasry net: skbuff: refcount spliced page_pool frags via skb_pipe_buf_ops This commit updates skb_splice_bits() and skb_append_pagefrags() to acquire and release fragment references via netmem_inc_ref(), netmem_dec_ref(), and skb_frag_ref() using a new skb_pipe_buf_ops table. > diff --git a/net/core/skbuff.c b/net/core/skbuff.c > index 48f6764117243..32a9dcdf2cb22 100644 > --- a/net/core/skbuff.c > +++ b/net/core/skbuff.c > @@ -3114,9 +3114,27 @@ EXPORT_SYMBOL(skb_copy_bits); > */ > static void sock_spd_release(struct splice_pipe_desc *spd, unsigned int = i) > { > - put_page(spd->pages[i]); > + netmem_dec_ref(page_to_netmem(spd->pages[i])); > } > =20 > +static void skb_pipe_buf_release(struct pipe_inode_info *pipe, > + struct pipe_buffer *buf) > +{ > + netmem_dec_ref(page_to_netmem(buf->page)); > +} > + > +static bool skb_pipe_buf_get(struct pipe_inode_info *pipe, > + struct pipe_buffer *buf) > +{ > + netmem_inc_ref(page_to_netmem(buf->page)); > + return true; > +} [Severity: High] Does replacing nosteal_pipe_buf_ops with skb_pipe_buf_ops in skb_splice_bit= s() drop the page reference count overflow check when pipe buffers are duplicat= ed? Previously, nosteal_pipe_buf_ops used generic_pipe_buf_get(), which calls try_get_page() and fails when the signed 32-bit page reference count is <= =3D 0: fs/pipe.c:generic_pipe_buf_get() { return try_get_page(buf->page); } include/linux/mm.h:try_get_page() { page =3D compound_head(page); if (WARN_ON_ONCE(page_ref_count(page) <=3D 0)) return false; page_ref_inc(page); return true; } With skb_pipe_buf_get(), duplicating a spliced pipe buffer via tee() -> link_pipe(), splice() -> splice_pipe_to_pipe(), or fuse_dev_splice_write() invokes skb_pipe_buf_get() -> netmem_inc_ref() -> get_page() and unconditionally returns true: include/net/netmem.h:netmem_inc_ref() { if (netmem_is_net_iov(netmem)) net_iov_inc_ref(netmem_to_net_iov(netmem)); else get_page(netmem_to_page(netmem)); } For any struct page-backed netmem using standard page refcounting (such as sk_page_frag() pages from linear_to_page(), non-page_pool RX fragments, user pages sent over a local socket, or page_pool pages whose pp_ref_count is 0,= as well as all struct pages at this commit prior to commit "net: remove skb->pp_recycle and consolidate netmem refcounting"), can repeated pipe buf= fer duplications push the page reference count past INT_MAX, triggering VM_BUG_ON_FOLIO(folio_ref_zero_or_close_to_overflow(folio), folio) under CONFIG_DEBUG_VM or wrapping _refcount to 0 and causing a use-after-free when CONFIG_DEBUG_VM is disabled? --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20261103211424.1276= 27-1-almasrymina@google.com?part=3D2