[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACT4Y+YZ-JR0iOX8MP9rnoYCwfz=9a+aM4L2LoUtJVko3=CkRQ@mail.gmail.com>
Date: Mon, 25 Oct 2021 08:37:45 +0200
From: Dmitry Vyukov <dvyukov@...gle.com>
To: Matthew Wilcox <willy@...radead.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
syzbot <syzbot+75639e6a0331cd61d3e2@...kaller.appspotmail.com>,
Andrew Morton <akpm@...ux-foundation.org>,
jordy@...dyzomer.github.io, jordy@...ing.systems,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux-MM <linux-mm@...ck.org>,
syzkaller-bugs <syzkaller-bugs@...glegroups.com>
Subject: Re: [syzbot] WARNING: refcount bug in memfd_secret
On Sun, 24 Oct 2021 at 22:12, Matthew Wilcox <willy@...radead.org> wrote:
>
> On Sun, Oct 24, 2021 at 09:54:22AM -1000, Linus Torvalds wrote:
> > On Sat, Oct 23, 2021 at 9:35 AM syzbot
> > <syzbot+75639e6a0331cd61d3e2@...kaller.appspotmail.com> wrote:
> > >
> > > syzbot found the following issue on:
> > >
> > > HEAD commit: 9c0c4d24ac00 Merge tag 'block-5.15-2021-10-22' of git://gi..
> > > git tree: upstream
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=115a0328b00000
> > > kernel config: https://syzkaller.appspot.com/x/.config?x=59f3ef2b4077575
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=75639e6a0331cd61d3e2
> > > compiler: Debian clang version 11.0.1-2, GNU ld (GNU Binutils for Debian) 2.35.2
> > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13a035c2b00000
> > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14ae869f300000
> > >
> > > The issue was bisected to:
> > >
> > > commit 110860541f443f950c1274f217a1a3e298670a33
> >
> > I think that commit is actually just buggy.
> >
> > "secretmem_users" is not actually a reference count. There's no "magic
> > happens when it goes down to zero".
> >
> > It's purely a count of the number of existing users, and incrementing
> > it from zero is not a probolem at all - it is in fact expected.
> >
> > Sure, zero means "we can hibernate", so zero and overflow are somewhat
> > special, but not special enough to cause these kinds of issues.
> >
> > I have reverted this commit in my tree, because honestly, the whole
> > "try to overflow exactly, and hibernate" threat model just isn't worth
> > this all.
> >
> > If people really care, I can suggest
> >
> > - use "atomic_long_t" instead. Let's face it, 32-bit isn't
> > interesting any more, and 64-bit doesn't overflow.
> >
> > - make up some new "atomic_inc_nooverflow()" thing or whatever.
> >
> > but for now this is just reverted.
>
> There was a separate thread on an earlier version of this report.
gcc and clang somehow produce different frames (I guess a tail call).
Need to fix parsing.
#syz dup: WARNING: refcount bug in sys_memfd_secret
> https://lore.kernel.org/linux-mm/YXU7%2FiRjf9v77gon@casper.infradead.org/
> I agree with you and suggested that if anybody really cares (I mean,
> you need a multi-TB machine to produce this problem) that we simply do
> what we did with the page refcount:
>
> +++ b/mm/secretmem.c
> @@ -203,6 +203,8 @@ SYSCALL_DEFINE1(memfd_secret, unsigned int, flags)
>
> if (flags & ~(SECRETMEM_FLAGS_MASK | O_CLOEXEC))
> return -EINVAL;
> + if (atomic_read(&secretmem_users) < 0)
> + return -ENFILE;
>
> fd = get_unused_fd_flags(flags & O_CLOEXEC);
> if (fd < 0)
>
> Mike didn't particularly like that answer though.
Powered by blists - more mailing lists