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: <20220701165039.96869-1-kuniyu@amazon.com>
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ