netdev - Re: [PATCH v1 net-next] af_unix: Put a named socket in the global hash table.

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]

Date:   Fri, 1 Jul 2022 09:50:39 -0700
From:   Kuniyuki Iwashima <kuniyu@...zon.com>
To:     <edumazet@...gle.com>
CC:     <cdleonard@...il.com>, <davem@...emloft.net>, <kuba@...nel.org>,
        <kuni1840@...il.com>, <kuniyu@...zon.com>,
        <netdev@...r.kernel.org>, <pabeni@...hat.com>,
        <sachinp@...ux.ibm.com>
Subject: Re: [PATCH v1 net-next] af_unix: Put a named socket in the global hash table.

From:   Eric Dumazet <edumazet@...gle.com>
Date:   Fri, 1 Jul 2022 18:36:21 +0200
> On Fri, Jul 1, 2022 at 9:25 AM Kuniyuki Iwashima <kuniyu@...zon.com> wrote:
> >
> > Commit cf2f225e2653 ("af_unix: Put a socket into a per-netns hash
> > table.") accidentally broke user API for named sockets.  A named
> > socket was able to connect() to a peer in the same mount namespace
> > even if they were in different network namespaces.
> >
> > The commit put all sockets into each per-netns hash table.  As a
> > result, connect() to a socket in a different netns failed to find
> > the peer and returned -ECONNREFUSED even when they had the same
> > mount namespace.
> >
> > We can reproduce this issue by
> >
> >   Console A:
> >
> >     # python3
> >     >>> from socket import *
> >     >>> s = socket(AF_UNIX, SOCK_STREAM, 0)
> >     >>> s.bind('test')
> >     >>> s.listen(32)
> >
> >   Console B:
> >
> >     # ip netns add test
> >     # ip netns exec test sh
> >     # python3
> >     >>> from socket import *
> >     >>> s = socket(AF_UNIX, SOCK_STREAM, 0)
> >     >>> s.connect('test')
> >
> 
> I think this deserves a new test perhaps...

Exactly.  I will add a selftest in v2.
Thank you.