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

Message-ID: <20230822162443.28625-1-kuniyu@amazon.com>
Date: Tue, 22 Aug 2023 09:24:43 -0700
From: Kuniyuki Iwashima <kuniyu@...zon.com>
To: <pabeni@...hat.com>
CC: <davem@...emloft.net>, <edumazet@...gle.com>, <kuba@...nel.org>,
	<kuni1840@...il.com>, <kuniyu@...zon.com>, <netdev@...r.kernel.org>
Subject: Re: [PATCH v1 net] net: Allow larger buffer than peer address for SO_PEERNAME.

From: Paolo Abeni <pabeni@...hat.com>
Date: Tue, 22 Aug 2023 10:43:06 +0200
> On Mon, 2023-08-21 at 19:40 -0700, Kuniyuki Iwashima wrote:
> > 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.
> 
> I'm unsure we can accept this change: AFAICS currently
> getsockopt(SO_PEERNAME,... len) never change the user-provided len on
> success. Applications could relay on that and avoid re-reading len on
> successful completion. With this patch such application could read
> uninitialized data and/or ever mis-interpret the peer name len.
> 
> If the user-space application want to avoid the binary search, it can
> already call getpeername().

Ah exactly, getppername() has the same behaviour with this patch
in move_addr_to_user().