Re: KASAN: use-after-free Read in path_lookupat

Re: KASAN: use-after-free Read in path_lookupat

[Al Viro]

On Tue, Mar 26, 2019 at 01:45:52AM +0000, Al Viro wrote:
> On Mon, Mar 25, 2019 at 11:37:32PM +0000, Al Viro wrote:
> 
> > For debugfs it's clearly "use default ->evict_inode(), have explicit
> > ->destroy_inode() using free_inode_nonrcu()" - there we have nothing
> > else done in ->evict_inode() and kfree is obviously safe in softirq.
> > I'll post that (or push to vfs.git#fixes), along with minimal fixes
> > for other 3.  If bpf_any_put() is softirq-safe, we'll have the full
> > set for -stable and the rest could be done on top of that.
> > 
> > Won't solve the documetation problem, unfortunately ;-/
> 
> Posted; all of those (as well as Daniel's bpf patch) are Cc:stable
> fodder.  Documentation is still, er, deficient...

... and unfortunately there are two more, exactly like debugfs -
securityfs and apparmorfs, found while sorting out the series
for separate rcu-delayed counterpart of ->destroy_inode().

Both are in vfs.git#fixes.  Which way should that go - directly or
via linux-security.git?  Both are stable fodder, in theory, but
much harder to hit than their ubifs/debugfs/bpf counterparts...

Re: KASAN: use-after-free Read in path_lookupat

[Linus Torvalds]

On Wed, Apr 10, 2019 at 8:11 AM Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> Both are in vfs.git#fixes.  Which way should that go - directly or
> via linux-security.git?

Just do it directly. I doubt you can trigger them for securityfs and
apparmourfs, since normal users have no way to remove any files from
them, so the race with final unlink sounds fairly irrelevant in
practice, no?

               Linus