Re: mm: shmem: NULL ptr deref in shmem_fault

2014-05-13 Thread Sasha Levin
On 05/13/2014 06:20 PM, Hugh Dickins wrote: > I haven't delved into the perf_even_mmap d_path (fs/dcache.c:2947) one, > but the Sys_mremap one on file->f_op->f_unmapped_area sounds like what > we have here: struct file has been freed. > > I believe Al is innocent: I point a quivering finger at...

Re: mm: shmem: NULL ptr deref in shmem_fault

2014-05-13 Thread Hugh Dickins
Adding Peter and Ingo from the perf_even_mmap thread, and Kirill. On Mon, 12 May 2014, Sasha Levin wrote: > On 05/12/2014 05:12 PM, Andrew Morton wrote: > > On Mon, 12 May 2014 10:26:17 -0400 Sasha Levin > > wrote: > > > >> Hi all, > >> > >> While fuzzing with trinity inside a KVM tools guest r

Re: mm: shmem: NULL ptr deref in shmem_fault

2014-05-12 Thread Sasha Levin
On 05/12/2014 05:12 PM, Andrew Morton wrote: > On Mon, 12 May 2014 10:26:17 -0400 Sasha Levin wrote: > >> Hi all, >> >> While fuzzing with trinity inside a KVM tools guest running the latest -next >> kernel I've stumbled on the following spew. >> >> It seems that in this case, 'inode->i_mapping'

Re: mm: shmem: NULL ptr deref in shmem_fault

2014-05-12 Thread Andrew Morton
On Mon, 12 May 2014 10:26:17 -0400 Sasha Levin wrote: > Hi all, > > While fuzzing with trinity inside a KVM tools guest running the latest -next > kernel I've stumbled on the following spew. > > It seems that in this case, 'inode->i_mapping' was NULL, and the deref > happened > when we tried t

Re: mm: shmem: NULL ptr deref in shmem_fault

2014-05-12 Thread Sasha Levin
On 05/12/2014 10:26 AM, Sasha Levin wrote: > Hi all, > > While fuzzing with trinity inside a KVM tools guest running the latest -next > kernel I've stumbled on the following spew. > > It seems that in this case, 'inode->i_mapping' was NULL, and the deref > happened > when we tried to get it's fl

mm: shmem: NULL ptr deref in shmem_fault

2014-05-12 Thread Sasha Levin
Hi all, While fuzzing with trinity inside a KVM tools guest running the latest -next kernel I've stumbled on the following spew. It seems that in this case, 'inode->i_mapping' was NULL, and the deref happened when we tried to get it's flags in mapping_gfp_mask(). [ 4431.615828] BUG: unable to ha