netdev - Re: [RFC] net: esp: fix bad handling of pages from page

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: <320ef2399e48ba0a8a11a3b258b7ad88384f42fb.camel@nvidia.com>
Date: Wed, 6 Mar 2024 16:00:46 +0000
From: Dragos Tatulea <dtatulea@...dia.com>
To: "kuba@...nel.org" <kuba@...nel.org>
CC: "davem@...emloft.net" <davem@...emloft.net>, "herbert@...dor.apana.org.au"
	<herbert@...dor.apana.org.au>, "dsahern@...nel.org" <dsahern@...nel.org>, Gal
 Pressman <gal@...dia.com>, "steffen.klassert@...unet.com"
	<steffen.klassert@...unet.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, Leon Romanovsky <leonro@...dia.com>,
	"pabeni@...hat.com" <pabeni@...hat.com>, "edumazet@...gle.com"
	<edumazet@...gle.com>, "almasrymina@...gle.com" <almasrymina@...gle.com>,
	"Anatoli.Chechelnickiy@...nterpipe.biz"
	<Anatoli.Chechelnickiy@...nterpipe.biz>, "ian.kumlien@...il.com"
	<ian.kumlien@...il.com>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [RFC] net: esp: fix bad handling of pages from page_pool

On Wed, 2024-03-06 at 07:22 -0800, Jakub Kicinski wrote:
> On Wed, 6 Mar 2024 13:05:14 +0000 Dragos Tatulea wrote:
> > On Tue, 2024-03-05 at 19:04 -0800, Jakub Kicinski wrote:
> > > On Mon, 4 Mar 2024 11:48:52 +0200 Dragos Tatulea wrote:  
> > > > When the skb is reorganized during esp_output (!esp->inline), the pages
> > > > coming from the original skb fragments are supposed to be released back
> > > > to the system through put_page. But if the skb fragment pages are
> > > > originating from a page_pool, calling put_page on them will trigger a
> > > > page_pool leak which will eventually result in a crash.  
> > > 
> > > So it just does: skb_shinfo(skb)->nr_frags = 1;
> > > and assumes that's equivalent to owning a page ref on all the frags?
> > >   
> > My understanding is different: it sets nr_frags to 1 because it's swapping out
> > the old page frag in fragment 0 with the new xfrag page frag and will use this
> > "new" skb from here. It does take a page reference for the xfrag page frag.
> 
> Same understanding, I'm just bad at explaining :)
> 
> > > Fix looks more or less good, we would need a new wrapper to avoid
> > > build issues without PAGE_POOL, 
> > >   
> > Ack. Which component would be best location for this wrapper: page_pool?
> 
> Hm, that's a judgment call.
> Part of me wants to put it next to napi_frag_unref(), since we
> basically need to factor out the insides of this function.
> When you post the patch the page pool crowd will give us
> their opinions.
> 
Why not have napi_pp_put_page simply return false if CONFIG_PAGE_POOL is not
set?

Regarding stable would I need to send a separate fix that does the raw pp page
check without the API?

> > > but I wonder if we wouldn't be better
> > > off changing the other side. Instead of "cutting off" the frags -
> > > walking them and dealing with various page types. Because Mina and co.
> > > will step onto this landmine as well.  
> > The page frags are still stored and used in the sg scatterlist. If we release
> > them at the moment when the skb is "cut off", the pages in the sg will be
> > invalid. At least that's my understanding.
> 
> I was thinking something along the lines of:
> 
> 	for each frag()
> 		if (is_pp_page()) {
> 			get_page();
> 			page_pool_unref_page(1);
> 		}
> 
> so that it's trivial to insert another check for "is this a zero-copy"
> page in there, and error our. But on reflection the zero copy check may
> be better placed in __skb_to_sgvec(), so ignore this. Just respin
> what you got with a new helper.
> 
Ignored. I was hoping we wouldn't go in that direction :).

Thanks,
Dragos