linux-kernel - RE: Re: Re: Re: [PATCH bpf v2] xsk: Fix out of order segment free in __xsk_generic

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: <20250604141521eucms1p26b794744fb73f84f223927c36ade7239@eucms1p2>
Date: Wed, 04 Jun 2025 16:15:21 +0200
From: Eryk Kubanski <e.kubanski@...tner.samsung.com>
To: Maciej Fijalkowski <maciej.fijalkowski@...el.com>
CC: Stanislav Fomichev <stfomichev@...il.com>, "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "bjorn@...nel.org" <bjorn@...nel.org>,
	"magnus.karlsson@...el.com" <magnus.karlsson@...el.com>,
	"jonathan.lemon@...il.com" <jonathan.lemon@...il.com>
Subject: RE: Re: Re: Re: [PATCH bpf v2] xsk: Fix out of order segment free
 in __xsk_generic_xmit()

> Thanks for shedding a bit more light on it. In the future it would be nice
> if you would be able to come up with a reproducer of a bug that others
> could use on their side. Plus the overview of your deployment from the
> beginning would also help with people understanding the issue :)

Sure, sorry for not giving that in advance, I found this issue
during code analysis, not during deployment.
It's not that simple to catch.
I thought that in finite time we will agree :D.
Next patchsets from me will have more information up-front.

> I'm looking into it, bottom line is that we discussed it with Magnus and
> agree that issue you're reporting needs to be addressed.
> I'll get back to you to discuss potential way of attacking it.
> Thanks!

Thank you.
Will this be discussed in the same mailing chain?

Technically we need to tie descriptor write-back
with skb lifetime.
xsk_build_skb() function builds skb for TX,
if i understand correctly this can work both ways
either we perform zero-copy, so specific buffer
page is attached to skb with given offset and size.
OR perform the copy.

If there was no zerocopy case, we could store it
on stack array and simply recycle descriptor back
right away without waiting for SKB completion.

This zero-copy case makes it impossible right?
We need to store these descriptors somewhere else
and tie it to SKB destruction :(.