Re: BUG: KASAN: use-after-free in xfs_iflush_cluster+0x9d7/0xaf0
From: Dave Chinner
Date: Tue Jan 05 2016 - 15:58:32 EST
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@xxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/