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]
Message-ID: <7577b0f5-2b43-4e5d-89fe-7129c32acb47@lunn.ch>
Date: Tue, 22 Jul 2025 19:41:01 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Kees Cook <kees@...nel.org>
Cc: "David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Simon Horman <horms@...nel.org>, netdev@...r.kernel.org,
	Andrew Lunn <andrew+netdev@...n.ch>, linux-kernel@...r.kernel.org,
	linux-hardening@...r.kernel.org
Subject: Re: [PATCH net-next] net: Document sockaddr safety in ARP and
 routing UAPI structures

On Tue, Jul 22, 2025 at 09:58:37AM -0700, Kees Cook wrote:
> Add documentation clarifying that ARP and routing UAPI structures are
> constrained to IPv4-only usage, making them safe for the coming fixed-size
> sockaddr conversion (with the 14-byte struct sockaddr::sa_data). These
> are fine as-is, but their use was non-obvious to me, so I figured they
> could use a little more documentation:
> 
> - struct arpreq: ARP protocol is IPv4-only by design
> - struct rtentry: Legacy IPv4 routing API, IPv6 uses different structures

I'm not sure this second statement is strictly true:

https://elixir.bootlin.com/linux/v6.15.7/source/net/appletalk/ddp.c#L918
atrtr_ioctl() ->
  atrtr_create()->
	struct sockaddr_at *ta = (struct sockaddr_at *)&r->rt_dst;

where:

struct sockaddr_at {
	__kernel_sa_family_t sat_family;
	__u8		  sat_port;
	struct atalk_addr sat_addr;
	char		  sat_zero[8];
};

This is not an IPv4 address.

Maybe this does fit with a 14 byte sockaddr::sa_data, so it is not an
issue, but the comment and commit message should be expanded to
explain this. And i only looked at the first SIOCADDRT i came across,
there are many other protocols using this ioctl.

	Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ