Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   ebiederm@xmission.com (Eric W. Biederman)
To:     Hillf Danton <hdanton@sina.com>
Cc:     syzbot <syzbot+b6e65bd125a05f803d6b@syzkaller.appspotmail.com>,
        legion@kernel.org, linux-kernel@vger.kernel.org,
        syzkaller-bugs@googlegroups.com
References: <000000000000efe97f05c74bb995@google.com>
        <20210719094432.425-1-hdanton@sina.com>
        <20210720041451.766-1-hdanton@sina.com>
Date:   Tue, 20 Jul 2021 11:29:09 -0500
In-Reply-To: <20210720041451.766-1-hdanton@sina.com> (Hillf Danton's message
        of "Tue, 20 Jul 2021 12:14:51 +0800")
Message-ID: <87y2a1q78q.fsf@disp2133>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [syzbot] KASAN: use-after-free Write in put_ucounts
Precedence: bulk

Hillf Danton <hdanton@sina.com> writes:

> On Mon, 19 Jul 2021 12:24:41 -0500 Eric W. Biederman wrote:
>>>
>>> To fix the uaf, add a couple of changes. Now only for thoughts.
>>>
>>> 1/ s/atomic_add_negative/atomic_inc_not_zero/ to correct the get
>>> method.
>>
>>I really don't think so.  The use of atomic_add_negative is very
>>deliberate.  Changing that fundamentally changes the algorithm into used
>
> Given atomic_dec_and_test() in put_ucounts(), what sense are you
> deliberately trying to make by bumping up a zero count?
>
>>to keep track of things.  Definitely not something to lead with.
>>
>>Before it even makes sense to talk about how to change the code,
>>a plausible explanation for how a use after free happens is needed.
>
> I am trying just to avoid touching zero count. That is it.

Observing a zero-reference count in this case is a result of a
use-after-free.  So that is definitely not what needs to be fixed.

>>That explanation should account for the fact this code was in linux-next
>>the since last -rc1 without any kind of issue with the test code.
>
> The code is no good without surviving syzbot, right? And -rcX does not
> matter.

That was with syzbot running against linux-next for 8ish weeks.

Something changed that syzbot is now reporting an error.

It is definitely worth fixing but we need to track down and understand
what the bug is.

Eric