[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240216214209.69408-1-kuniyu@amazon.com>
Date: Fri, 16 Feb 2024 13:42:09 -0800
From: Kuniyuki Iwashima <kuniyu@...zon.com>
To: <edumazet@...gle.com>
CC: <davem@...emloft.net>, <kuba@...nel.org>, <kuni1840@...il.com>,
<kuniyu@...zon.com>, <netdev@...r.kernel.org>, <pabeni@...hat.com>
Subject: Re: [PATCH v2 net-next 00/14] af_unix: Rework GC.
From: Eric Dumazet <edumazet@...gle.com>
Date: Fri, 16 Feb 2024 22:28:11 +0100
> On Fri, Feb 16, 2024 at 10:06 PM Kuniyuki Iwashima <kuniyu@...zon.com> wrote:
> >
> > When we pass a file descriptor to an AF_UNIX socket via SCM_RIGTHS,
> > the underlying struct file of the inflight fd gets its refcount bumped.
> > If the fd is of an AF_UNIX socket, we need to track it in case it forms
> > cyclic references.
> >
> > Let's say we send a fd of AF_UNIX socket A to B and vice versa and
> > close() both sockets.
> >
> > When created, each socket's struct file initially has one reference.
> > After the fd exchange, both refcounts are bumped up to 2. Then, close()
> > decreases both to 1. From this point on, no one can touch the file/socket.
>
> Note that I have pending syzbot reports about af_unix. (apparently
> syzbot found its way with SO_PEEK_OFF)
Interesting :)
>
> I would prefer we wait a bit before reworking the whole thing.
Sure, I'll wait to avoid a sad situation that large refactoring
happens to fix the bug and we need to backport or cook another
fix for stable.
Powered by blists - more mailing lists