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
| ||
|
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.
Powered by blists - more mailing lists