netdev - Re: [PATCH v1 net] net: Allow larger buffer than peer address for SO

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: <20230822024011.4978-1-kuniyu@amazon.com>
Date: Mon, 21 Aug 2023 19:40:11 -0700
From: Kuniyuki Iwashima <kuniyu@...zon.com>
To: <kuba@...nel.org>
CC: <davem@...emloft.net>, <edumazet@...gle.com>, <kuni1840@...il.com>,
	<kuniyu@...zon.com>, <netdev@...r.kernel.org>, <pabeni@...hat.com>
Subject: Re: [PATCH v1 net] net: Allow larger buffer than peer address for SO_PEERNAME.

From: Jakub Kicinski <kuba@...nel.org>
Date: Mon, 21 Aug 2023 19:11:13 -0700
> On Fri, 18 Aug 2023 17:55:52 -0700 Kuniyuki Iwashima wrote:
> > For example, we usually do not know the peer name if we get an AF_UNIX
> > socket by accept(), FD passing, or pidfd_getfd().  Then we get -EINVAL
> > if we pass sizeof(struct sockaddr_un) to getsockopt(SO_PEERNAME).  So,
> > we need to do binary search to get the exact peer name.
> 
> Sounds annoying indeed, but is it really a fix?

So, is net-next preferable ?

I don't have a strong opinion, but I thought "Before knowing the peer
name, you have to know the length" is a bug in the logic, at least for
AF_UNIX.