Received-SPF: temperror (google.com: error in processing during lookup of linux-kernel-owner@vger.kernel.org: DNS error) client-ip=209.132.180.67;
Date:   Mon, 25 Mar 2019 11:11:23 +0000
From:   Al Viro <viro@zeniv.linux.org.uk>
To:     Daniel Borkmann <daniel@iogearbox.net>
Cc:     Linus Torvalds <torvalds@linux-foundation.org>,
        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>
Subject: Re: KASAN: use-after-free Read in path_lookupat
Message-ID: <20190325111123.GM2217@ZenIV.linux.org.uk>
References: <0000000000006946d2057bbd0eef@google.com>
 <CAHk-=wiijJMTw=nTj_ED+YWMCrvHzh3ezfVYRxvzcW6+trgyPA@mail.gmail.com>
 <20190325045744.GK2217@ZenIV.linux.org.uk>
 <717eaff9-1f49-28f3-bbb6-c8f14ebbe03b@iogearbox.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <717eaff9-1f49-28f3-bbb6-c8f14ebbe03b@iogearbox.net>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Mar 25, 2019 at 10:15:40AM +0100, Daniel Borkmann wrote:
> > So we have 5 broken cases, all with the same kind of fix: move freeing
> > into the RCU-delayed part of ->destroy_inode(); for debugfs and bpf
> > that requires adding ->alloc_inode()/->destroy_inode(), rather than
> > relying upon the defaults from fs/inode.c
> 
> I believe I copied that logic from one of the other fs'es back then, sigh.
> Thanks for the analysis and hints for fixing. Would the below (only compile
> tested for now) look reasonable to you? I believe there is no other way
> around than to add our own inode cache, but so be it. The freeing of the
> i_link is then RCU-deferred in bpf_destroy_inode_deferred():

It looks like it would suffice, but it's way too much boilerplate for my
taste ;-/

Most of your headache here comes from messing with slab setup and the
only reason for that is being unable to free stuff into inode_cachep.
So grep for inode_cachep would be a good idea, and it digs up the
following sucker:
void free_inode_nonrcu(struct inode *inode)  
{
        kmem_cache_free(inode_cachep, inode);
}
EXPORT_SYMBOL(free_inode_nonrcu);

IOW, you need nothing on ->alloc_inode() side and for ->destroy_inode()
just do call_rcu() of a callback, that would kfree(inode->link) if
it was a symlink, then call free_inode_nonrcu(inode).

Considerably smaller patch that way...