Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <0000000000006946d2057bbd0eef@google.com> <CAHk-=wiijJMTw=nTj_ED+YWMCrvHzh3ezfVYRxvzcW6+trgyPA@mail.gmail.com>
 <20190325045744.GK2217@ZenIV.linux.org.uk> <CAHk-=wg4iJsMHBzK52WzP+5_92HbwvX_vh_s4mMUuN0FJGdM5A@mail.gmail.com>
 <CAHk-=whJ4M5FegOLvnjUtJ0+pHv4L8UNFt+9jJDhox3Ada8kwA@mail.gmail.com>
 <20190325211405.GP2217@ZenIV.linux.org.uk> <CAHk-=wj+-e=X9cvvNwc5+QuvBOyYT7OtZTBzy-Wg8zGrUwxSbw@mail.gmail.com>
 <f4eccb87-1ea2-c0d5-19db-d638f2c5aa57@iogearbox.net>
In-Reply-To: <f4eccb87-1ea2-c0d5-19db-d638f2c5aa57@iogearbox.net>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon, 25 Mar 2019 15:13:40 -0700
Message-ID: <CAHk-=wjD-A_VsYC_OKcn30_ZsrLEE1CN7mnwZ803cvaFTdTTfA@mail.gmail.com>
Subject: Re: KASAN: use-after-free Read in path_lookupat
To:     Daniel Borkmann <daniel@iogearbox.net>
Cc:     Al Viro <viro@zeniv.linux.org.uk>,
        syzbot <syzbot+7a8ba368b47fdefca61e@syzkaller.appspotmail.com>,
        Alexei Starovoitov <ast@kernel.org>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
        syzkaller-bugs <syzkaller-bugs@googlegroups.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Mar 25, 2019 at 3:04 PM Daniel Borkmann <daniel@iogearbox.net> wrote:
>
> I'm fine either way, I think the rcu_destroy_inode would indeed simplify
> it nicely. In any case fwiw, here's what I'd have ready for standby on bpf
> side and tested as well. Decided to get rid of bpf_evict_inode() entirely
> since the only callback we'd really need is on final inode destruction:

Yes, this looks correct to me.

I think this is worth doing regardless. Even if we then make the vfs
layer add that rcu_destroy_inode(), that will fit very well with this
patch, and getting rid of the special bpf_evict_inode() logic and just
letting the normal vfs inode cleanup happen looks like the right
thing.

So ack from me on your

> Subject: [PATCH bpf] bpf: fix use after free in bpf_evict_inode

patch regardless of what else we might end up doing in this area to
clean things up.

                 Linus