Re: BUG: KASAN: use-after-free in xfs_iflush_cluster+0x9d7/0xaf0

[Dave Chinner <david@fromorbit.com>]

On Tue, Jan 05, 2016 at 05:30:55PM +0100, Andrea Gelmini wrote:
> On Mon, Jan 04, 2016 at 07:47:58AM +1100, Dave Chinner wrote:
> > > I'm recompiling, to try it again.
> > > Maybe, in the meanwhile, you can do something with my files. You can find 'em here:
> > > http://mail.gelma.net/xfs_kasan
> >
> > Any update on this problem, Andrea?
> 
> Here we are!
> Reproduced right now.
> 
> So, just to avoid confusion:
> a) it's a vanilla kernel 4.4.0-rc8
> b) plus some btrfs patches
> c) plus some dri/intel/i915 patches
> d) at the same URL above you can find git_files.txt.gz, where you have each commit I
>    applied above vanilla kernel (anyway, nothing related to vfs/xfs of course)
> e) at the same URL you find the kernel binaries I used
> f) to catch it, I had to copy a few gigs of files on my /home partition (xfs over Luks)
> 
> Anyway, here what you asked me for:
> 
> (gdb) l *(xfs_iflush_cluster+0xb73/0xc10)
> 0xffffffff8184c550 is in xfs_iflush_cluster (fs/xfs/xfs_inode.c:3182).
> 3177
> 3178    STATIC int
> 3179    xfs_iflush_cluster(
> 3180            xfs_inode_t     *ip,
> 3181            xfs_buf_t       *bp)
> 3182    {
> 3183            xfs_mount_t             *mp = ip->i_mount;
> 3184            struct xfs_perag        *pag;
> 3185            unsigned long           first_index, mask;
> 3186            unsigned long           inodes_per_cluster;
> (gdb)

Ok, so that tells us nothing about where the problem lies - the
function call is out of the preamble code that kasan instrumentation
adds to the function. I'll have a further think about this...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com