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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZqI29QE+5JnkdPmE@boxer>
Date: Thu, 25 Jul 2024 13:28:53 +0200
From: Maciej Fijalkowski <maciej.fijalkowski@...el.com>
To: Daniel Borkmann <daniel@...earbox.net>
CC: Stanislav Fomichev <sdf@...ichev.me>, <bpf@...r.kernel.org>,
	<netdev@...r.kernel.org>, <ast@...nel.org>, <andrii@...nel.org>,
	<martin.lau@...ux.dev>, <song@...nel.org>, <yhs@...com>,
	<john.fastabend@...il.com>, <kpsingh@...nel.org>, <sdf@...gle.com>,
	<haoluo@...gle.com>, <jolsa@...nel.org>, Julian Schindel
	<mail@...tic-alpaca.de>, Magnus Karlsson <magnus.karlsson@...il.com>
Subject: Re: [PATCH bpf 0/3] xsk: require XDP_UMEM_TX_METADATA_LEN to actuate
 tx_metadata_len

On Thu, Jul 25, 2024 at 12:06:22PM +0200, Daniel Borkmann wrote:
> On 7/24/24 5:23 PM, Maciej Fijalkowski wrote:
> > On Fri, Jul 12, 2024 at 06:52:50PM -0700, Stanislav Fomichev wrote:
> > > Julian reports that commit 341ac980eab9 ("xsk: Support tx_metadata_len")
> > > can break existing use cases which don't zero-initialize xdp_umem_reg
> > > padding. Fix it (while still breaking a minority of new users of tx
> > > metadata), update the docs, update the selftest and sprinkle some
> > > BUILD_BUG_ONs to hopefully catch similar issues in the future.
> > > 
> > > Thank you Julian for the report and for helping to chase it down!
> > > 
> > > Reported-by: Julian Schindel <mail@...tic-alpaca.de>
> > > Cc: Magnus Karlsson <magnus.karlsson@...il.com>
> > 
> > For the content series,
> > 
> > Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@...el.com>
> > 
> > However I was not sure about handling patch 3/3.
> 
> Ok, then I'm taking in the first two for now as they seem to actually
> address the fix and the 3rd seems like an improvement which could also
> get routed via bpf-next. In either case, if one of you could follow-up
> on the latter, that would be great.

My first thought was about squashing 1 and 3 but I hope Stan doesn't mind
sending 3 solely to bpf-next...

> 
> Thanks,
> Daniel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ