netdev - Re: [PATCH net] ipv{4,6}/raw: fix output xfrm lookup wrt protocol

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] [day] [month] [year] [list]

Date: Mon, 15 May 2023 12:29:21 +0200
From: Steffen Klassert <steffen.klassert@...unet.com>
To: Nicolas Dichtel <nicolas.dichtel@...nd.com>
CC: "David S . Miller" <davem@...emloft.net>, Jakub Kicinski
	<kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Eric Dumazet
	<edumazet@...gle.com>, Steffen Klassert <klassert@...nel.org>,
	<netdev@...r.kernel.org>
Subject: Re: [PATCH net] ipv{4,6}/raw: fix output xfrm lookup wrt protocol

On Mon, May 15, 2023 at 09:02:05AM +0200, Nicolas Dichtel wrote:
> Hi,
> 
> Le 11/05/2023 à 16:19, Nicolas Dichtel a écrit :
> > With a raw socket bound to IPPROTO_RAW (ie with hdrincl enabled), the
> > protocol field of the flow structure, build by raw_sendmsg() /
> > rawv6_sendmsg()),  is set to IPPROTO_RAW. This breaks the ipsec policy
> > lookup when some policies are defined with a protocol in the selector.
> > 
> > For ipv6, the sin6_port field from 'struct sockaddr_in6' could be used to
> > specify the protocol. Just accept all values for IPPROTO_RAW socket.
> > 
> > For ipv4, the sin_port field of 'struct sockaddr_in' could not be used
> > without breaking backward compatibility (the value of this field was never
> > checked). Let's add a new kind of control message, so that the userland
> > could specify which protocol is used.
> > 
> > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > Signed-off-by: Nicolas Dichtel <nicolas.dichtel@...nd.com>
> The patch has been marked 'Awaiting Upstream' in the patchwork. But, I targeted
> the 'net' tree.
> Should I target the 'ipsec' tree? Or am I missing something?

It does not touch ipsec code at all, so IMO the 'net' tree
should be the right target.