* mm: shmem: NULL ptr deref in shmem_fault
@ 2014-05-12 14:26 ` Sasha Levin
0 siblings, 0 replies; 12+ messages in thread
From: Sasha Levin @ 2014-05-12 14:26 UTC (permalink / raw)
To: Hugh Dickins, Andrew Morton; +Cc: Dave Jones, linux-mm, LKML
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 handle kernel NULL pointer dereference at 0000000000000030
[ 4431.617708] IP: shmem_fault (mm/shmem.c:2960 mm/shmem.c:1236)
[ 4431.621711] PGD 1d7fb5067 PUD 1d7fb4067 PMD 0
[ 4431.621945] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
[ 4431.621945] Dumping ftrace buffer:
[ 4431.621945] (ftrace buffer empty)
[ 4431.621945] Modules linked in:
[ 4431.621945] CPU: 1 PID: 20571 Comm: trinity-c61 Not tainted 3.15.0-rc5-next-20140512-sasha-00019-ga20bc00-dirty #456
[ 4431.621945] task: ffff8803333e0000 ti: ffff88032b562000 task.ti: ffff88032b562000
[ 4431.621945] RIP: shmem_fault (mm/shmem.c:2960 mm/shmem.c:1236)
[ 4431.621945] RSP: 0018:ffff88032b5639b8 EFLAGS: 00010296
[ 4431.621945] RAX: ffff88005daab100 RBX: ffff88005db19e00 RCX: 0000000000000001
[ 4431.621945] RDX: 0000000000000001 RSI: ffff88032b5639f8 RDI: 0000000000000000
[ 4431.621945] RBP: ffff88032b5639d8 R08: ffff88032b563a70 R09: ffff88032b5639c4
[ 4431.621945] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8801caad2ed0
[ 4431.621945] R13: ffff8801ca27c7e8 R14: 0000000000000000 R15: ffff88005db19e00
[ 4431.621945] FS: 00007f8c3b4ef700(0000) GS:ffff88006ec00000(0000) knlGS:0000000000000000
[ 4431.621945] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 4431.621945] CR2: 0000000000000030 CR3: 00000001d7fb6000 CR4: 00000000000006a0
[ 4431.621945] DR0: 00000000006df000 DR1: 0000000000000000 DR2: 0000000000000000
[ 4431.621945] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600
[ 4431.621945] Stack:
[ 4431.621945] ffffffff8a2bb583 0000020000000286 ffff88032b563a18 ffff88032b563a70
[ 4431.621945] ffff88032b563a38 ffffffff8a2b83d9 ffff8801e71f8338 00000000ffffffff
[ 4431.621945] ffff880300000000 0000000000000001 00007f8c3b4fd000 0000000000000000
[ 4431.621945] Call Trace:
[ 4431.621945] ? do_read_fault.isra.40 (mm/memory.c:2882)
[ 4431.621945] __do_fault (mm/memory.c:2703)
[ 4431.621945] ? _raw_spin_unlock (arch/x86/include/asm/preempt.h:98 include/linux/spinlock_api_smp.h:152 kernel/locking/spinlock.c:183)
[ 4431.621945] do_read_fault.isra.40 (mm/memory.c:2883)
[ 4431.621945] ? get_parent_ip (kernel/sched/core.c:2519)
[ 4431.621945] ? get_parent_ip (kernel/sched/core.c:2519)
[ 4431.621945] __handle_mm_fault (mm/memory.c:3021 mm/memory.c:3182 mm/memory.c:3306)
[ 4431.621945] ? __const_udelay (arch/x86/lib/delay.c:126)
[ 4431.621945] ? __rcu_read_unlock (kernel/rcu/update.c:97)
[ 4431.621945] handle_mm_fault (mm/memory.c:3329)
[ 4431.621945] __get_user_pages (mm/gup.c:281 mm/gup.c:466)
[ 4431.621945] ? preempt_count_sub (kernel/sched/core.c:2575)
[ 4431.621945] get_user_pages (mm/gup.c:632)
[ 4431.621945] get_user_pages_fast (arch/x86/mm/gup.c:394)
[ 4431.621945] vmsplice_to_pipe (fs/splice.c:1487 fs/splice.c:1607)
[ 4431.621945] ? page_cache_pipe_buf_release (fs/splice.c:267)
[ 4431.621945] ? kvm_clock_read (arch/x86/include/asm/preempt.h:90 arch/x86/kernel/kvmclock.c:86)
[ 4431.621945] ? sched_clock (arch/x86/include/asm/paravirt.h:192 arch/x86/kernel/tsc.c:305)
[ 4431.621945] ? sched_clock_local (kernel/sched/clock.c:214)
[ 4431.621945] ? vtime_account_user (kernel/sched/cputime.c:687)
[ 4431.621945] ? debug_smp_processor_id (lib/smp_processor_id.c:57)
[ 4431.621945] ? put_lock_stats.isra.12 (arch/x86/include/asm/preempt.h:98 kernel/locking/lockdep.c:254)
[ 4431.621945] ? vtime_account_user (kernel/sched/cputime.c:687)
[ 4431.621945] ? get_parent_ip (kernel/sched/core.c:2519)
[ 4431.621945] ? get_parent_ip (kernel/sched/core.c:2519)
[ 4431.621945] ? __fget_light (include/linux/rcupdate.h:428 include/linux/fdtable.h:80 fs/file.c:684)
[ 4431.621945] SyS_vmsplice (fs/splice.c:1650 fs/splice.c:1636)
[ 4431.621945] tracesys (arch/x86/kernel/entry_64.S:746)
[ 4431.621945] Code: 66 66 66 90 55 b9 01 00 00 00 48 89 e5 53 48 89 fb 4c 8d 4d ec 48 83 ec 18 c7 45 ec 00 02 00 00 48 8b 87 a0 00 00 00 48 8b 78 20 <48> 8b 57 30 4c 8b 82 48 01 00 00 48 8d 56 18 48 8b 76 08 41 81
[ 4431.621945] RIP shmem_fault (mm/shmem.c:2960 mm/shmem.c:1236)
[ 4431.621945] RSP <ffff88032b5639b8>
[ 4431.621945] CR2: 0000000000000030
Thanks,
Sasha
^ permalink raw reply [flat|nested] 12+ messages in thread
* mm: shmem: NULL ptr deref in shmem_fault
@ 2014-05-12 14:26 ` Sasha Levin
0 siblings, 0 replies; 12+ messages in thread
From: Sasha Levin @ 2014-05-12 14:26 UTC (permalink / raw)
To: Hugh Dickins, Andrew Morton; +Cc: Dave Jones, linux-mm, LKML
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 handle kernel NULL pointer dereference at 0000000000000030
[ 4431.617708] IP: shmem_fault (mm/shmem.c:2960 mm/shmem.c:1236)
[ 4431.621711] PGD 1d7fb5067 PUD 1d7fb4067 PMD 0
[ 4431.621945] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
[ 4431.621945] Dumping ftrace buffer:
[ 4431.621945] (ftrace buffer empty)
[ 4431.621945] Modules linked in:
[ 4431.621945] CPU: 1 PID: 20571 Comm: trinity-c61 Not tainted 3.15.0-rc5-next-20140512-sasha-00019-ga20bc00-dirty #456
[ 4431.621945] task: ffff8803333e0000 ti: ffff88032b562000 task.ti: ffff88032b562000
[ 4431.621945] RIP: shmem_fault (mm/shmem.c:2960 mm/shmem.c:1236)
[ 4431.621945] RSP: 0018:ffff88032b5639b8 EFLAGS: 00010296
[ 4431.621945] RAX: ffff88005daab100 RBX: ffff88005db19e00 RCX: 0000000000000001
[ 4431.621945] RDX: 0000000000000001 RSI: ffff88032b5639f8 RDI: 0000000000000000
[ 4431.621945] RBP: ffff88032b5639d8 R08: ffff88032b563a70 R09: ffff88032b5639c4
[ 4431.621945] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8801caad2ed0
[ 4431.621945] R13: ffff8801ca27c7e8 R14: 0000000000000000 R15: ffff88005db19e00
[ 4431.621945] FS: 00007f8c3b4ef700(0000) GS:ffff88006ec00000(0000) knlGS:0000000000000000
[ 4431.621945] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 4431.621945] CR2: 0000000000000030 CR3: 00000001d7fb6000 CR4: 00000000000006a0
[ 4431.621945] DR0: 00000000006df000 DR1: 0000000000000000 DR2: 0000000000000000
[ 4431.621945] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600
[ 4431.621945] Stack:
[ 4431.621945] ffffffff8a2bb583 0000020000000286 ffff88032b563a18 ffff88032b563a70
[ 4431.621945] ffff88032b563a38 ffffffff8a2b83d9 ffff8801e71f8338 00000000ffffffff
[ 4431.621945] ffff880300000000 0000000000000001 00007f8c3b4fd000 0000000000000000
[ 4431.621945] Call Trace:
[ 4431.621945] ? do_read_fault.isra.40 (mm/memory.c:2882)
[ 4431.621945] __do_fault (mm/memory.c:2703)
[ 4431.621945] ? _raw_spin_unlock (arch/x86/include/asm/preempt.h:98 include/linux/spinlock_api_smp.h:152 kernel/locking/spinlock.c:183)
[ 4431.621945] do_read_fault.isra.40 (mm/memory.c:2883)
[ 4431.621945] ? get_parent_ip (kernel/sched/core.c:2519)
[ 4431.621945] ? get_parent_ip (kernel/sched/core.c:2519)
[ 4431.621945] __handle_mm_fault (mm/memory.c:3021 mm/memory.c:3182 mm/memory.c:3306)
[ 4431.621945] ? __const_udelay (arch/x86/lib/delay.c:126)
[ 4431.621945] ? __rcu_read_unlock (kernel/rcu/update.c:97)
[ 4431.621945] handle_mm_fault (mm/memory.c:3329)
[ 4431.621945] __get_user_pages (mm/gup.c:281 mm/gup.c:466)
[ 4431.621945] ? preempt_count_sub (kernel/sched/core.c:2575)
[ 4431.621945] get_user_pages (mm/gup.c:632)
[ 4431.621945] get_user_pages_fast (arch/x86/mm/gup.c:394)
[ 4431.621945] vmsplice_to_pipe (fs/splice.c:1487 fs/splice.c:1607)
[ 4431.621945] ? page_cache_pipe_buf_release (fs/splice.c:267)
[ 4431.621945] ? kvm_clock_read (arch/x86/include/asm/preempt.h:90 arch/x86/kernel/kvmclock.c:86)
[ 4431.621945] ? sched_clock (arch/x86/include/asm/paravirt.h:192 arch/x86/kernel/tsc.c:305)
[ 4431.621945] ? sched_clock_local (kernel/sched/clock.c:214)
[ 4431.621945] ? vtime_account_user (kernel/sched/cputime.c:687)
[ 4431.621945] ? debug_smp_processor_id (lib/smp_processor_id.c:57)
[ 4431.621945] ? put_lock_stats.isra.12 (arch/x86/include/asm/preempt.h:98 kernel/locking/lockdep.c:254)
[ 4431.621945] ? vtime_account_user (kernel/sched/cputime.c:687)
[ 4431.621945] ? get_parent_ip (kernel/sched/core.c:2519)
[ 4431.621945] ? get_parent_ip (kernel/sched/core.c:2519)
[ 4431.621945] ? __fget_light (include/linux/rcupdate.h:428 include/linux/fdtable.h:80 fs/file.c:684)
[ 4431.621945] SyS_vmsplice (fs/splice.c:1650 fs/splice.c:1636)
[ 4431.621945] tracesys (arch/x86/kernel/entry_64.S:746)
[ 4431.621945] Code: 66 66 66 90 55 b9 01 00 00 00 48 89 e5 53 48 89 fb 4c 8d 4d ec 48 83 ec 18 c7 45 ec 00 02 00 00 48 8b 87 a0 00 00 00 48 8b 78 20 <48> 8b 57 30 4c 8b 82 48 01 00 00 48 8d 56 18 48 8b 76 08 41 81
[ 4431.621945] RIP shmem_fault (mm/shmem.c:2960 mm/shmem.c:1236)
[ 4431.621945] RSP <ffff88032b5639b8>
[ 4431.621945] CR2: 0000000000000030
Thanks,
Sasha
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: mm: shmem: NULL ptr deref in shmem_fault
2014-05-12 14:26 ` Sasha Levin
@ 2014-05-12 14:58 ` Sasha Levin
-1 siblings, 0 replies; 12+ messages in thread
From: Sasha Levin @ 2014-05-12 14:58 UTC (permalink / raw)
To: Hugh Dickins, Andrew Morton; +Cc: Dave Jones, linux-mm, LKML
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 flags in mapping_gfp_mask().
And another one, which seems to be related. Here it seems that inode->policy was
invalid:
[ 610.862199] BUG: unable to handle kernel paging request at ffffffffffffff48
[ 610.863416] IP: mpol_shared_policy_lookup (mm/mempolicy.c:2202)
[ 610.864598] PGD 2c02f067 PUD 2c031067 PMD 0
[ 610.865360] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
[ 610.866325] Dumping ftrace buffer:
[ 610.867017] (ftrace buffer empty)
[ 610.867689] Modules linked in:
[ 610.868697] CPU: 12 PID: 13939 Comm: trinity-c101 Not tainted 3.15.0-rc5-next-20140512-sasha-00019-ga20bc00-dirty #456
[ 610.870051] task: ffff880291403000 ti: ffff880291124000 task.ti: ffff880291124000
[ 610.870051] RIP: mpol_shared_policy_lookup (mm/mempolicy.c:2202)
[ 610.870051] RSP: 0018:ffff880291125e48 EFLAGS: 00010286
[ 610.870051] RAX: ffff8802bb80b800 RBX: ffffffffffffff48 RCX: ffffffffae748740
[ 610.870051] RDX: ffffffffa72a3b20 RSI: 0000000000000001 RDI: ffffffffffffff48
[ 610.870051] RBP: ffff880291125e68 R08: ffff88036620e4b8 R09: 0000000000000000
[ 610.870051] R10: 0000000000000001 R11: 0000000000000000 R12: 000000000000cf54
[ 610.870051] R13: 00007fe57c76f000 R14: ffff8802fd0a7200 R15: ffff880291403000
[ 610.870051] FS: 00007fe57c76d700(0000) GS:ffff8802fee00000(0000) knlGS:0000000000000000
[ 610.870051] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 610.870051] CR2: ffffffffffffff48 CR3: 0000000291108000 CR4: 00000000000006a0
[ 610.870051] DR0: 00000000006df000 DR1: 00000000006df000 DR2: 00000000006df000
[ 610.886009] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000602
[ 610.886009] Stack:
[ 610.886009] ffff88029114e800 ffff88036620e000 000000000000cf54 00007fe57c76f000
[ 610.886009] ffff880291125e78 ffffffffa72a3b4e ffff880291125e98 ffffffffa72e16a2
[ 610.886009] 000000000000cf54 00007fe57c76f000 ffff880291125ef8 ffffffffa71a9f3b
[ 610.886009] Call Trace:
[ 610.886009] shmem_get_policy (mm/shmem.c:1262)
[ 610.886009] vma_policy_mof (mm/mempolicy.c:1609)
[ 610.886009] task_numa_work (kernel/sched/fair.c:1905)
[ 610.886009] ? context_tracking_user_exit (arch/x86/include/asm/paravirt.h:809 (discriminator 2) kernel/context_tracking.c:182 (discriminator 2))
[ 610.886009] task_work_run (kernel/task_work.c:125 (discriminator 1))
[ 610.886009] do_notify_resume (include/linux/tracehook.h:196 arch/x86/kernel/signal.c:753)
[ 610.886009] int_signal (arch/x86/kernel/entry_64.S:804)
[ 610.886009] Code: 66 66 66 90 55 48 89 e5 e8 02 ff ff ff 5d c3 66 66 66 66 90 55 48 89 e5 48 83 ec 20 48 89 5d e8 48 89 fb 4c 89 65 f0 4c 89 6d f8 <48> 83 3f 00 74 4e 4c 8d 6f 08 49 89 f4 4c 89 ef e8 4f 85 2a 03
[ 610.886009] RIP mpol_shared_policy_lookup (mm/mempolicy.c:2202)
[ 610.886009] RSP <ffff880291125e48>
[ 610.886009] CR2: ffffffffffffff48
Thanks,
Sasha
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: mm: shmem: NULL ptr deref in shmem_fault
@ 2014-05-12 14:58 ` Sasha Levin
0 siblings, 0 replies; 12+ messages in thread
From: Sasha Levin @ 2014-05-12 14:58 UTC (permalink / raw)
To: Hugh Dickins, Andrew Morton; +Cc: Dave Jones, linux-mm, LKML
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 flags in mapping_gfp_mask().
And another one, which seems to be related. Here it seems that inode->policy was
invalid:
[ 610.862199] BUG: unable to handle kernel paging request at ffffffffffffff48
[ 610.863416] IP: mpol_shared_policy_lookup (mm/mempolicy.c:2202)
[ 610.864598] PGD 2c02f067 PUD 2c031067 PMD 0
[ 610.865360] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
[ 610.866325] Dumping ftrace buffer:
[ 610.867017] (ftrace buffer empty)
[ 610.867689] Modules linked in:
[ 610.868697] CPU: 12 PID: 13939 Comm: trinity-c101 Not tainted 3.15.0-rc5-next-20140512-sasha-00019-ga20bc00-dirty #456
[ 610.870051] task: ffff880291403000 ti: ffff880291124000 task.ti: ffff880291124000
[ 610.870051] RIP: mpol_shared_policy_lookup (mm/mempolicy.c:2202)
[ 610.870051] RSP: 0018:ffff880291125e48 EFLAGS: 00010286
[ 610.870051] RAX: ffff8802bb80b800 RBX: ffffffffffffff48 RCX: ffffffffae748740
[ 610.870051] RDX: ffffffffa72a3b20 RSI: 0000000000000001 RDI: ffffffffffffff48
[ 610.870051] RBP: ffff880291125e68 R08: ffff88036620e4b8 R09: 0000000000000000
[ 610.870051] R10: 0000000000000001 R11: 0000000000000000 R12: 000000000000cf54
[ 610.870051] R13: 00007fe57c76f000 R14: ffff8802fd0a7200 R15: ffff880291403000
[ 610.870051] FS: 00007fe57c76d700(0000) GS:ffff8802fee00000(0000) knlGS:0000000000000000
[ 610.870051] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 610.870051] CR2: ffffffffffffff48 CR3: 0000000291108000 CR4: 00000000000006a0
[ 610.870051] DR0: 00000000006df000 DR1: 00000000006df000 DR2: 00000000006df000
[ 610.886009] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000602
[ 610.886009] Stack:
[ 610.886009] ffff88029114e800 ffff88036620e000 000000000000cf54 00007fe57c76f000
[ 610.886009] ffff880291125e78 ffffffffa72a3b4e ffff880291125e98 ffffffffa72e16a2
[ 610.886009] 000000000000cf54 00007fe57c76f000 ffff880291125ef8 ffffffffa71a9f3b
[ 610.886009] Call Trace:
[ 610.886009] shmem_get_policy (mm/shmem.c:1262)
[ 610.886009] vma_policy_mof (mm/mempolicy.c:1609)
[ 610.886009] task_numa_work (kernel/sched/fair.c:1905)
[ 610.886009] ? context_tracking_user_exit (arch/x86/include/asm/paravirt.h:809 (discriminator 2) kernel/context_tracking.c:182 (discriminator 2))
[ 610.886009] task_work_run (kernel/task_work.c:125 (discriminator 1))
[ 610.886009] do_notify_resume (include/linux/tracehook.h:196 arch/x86/kernel/signal.c:753)
[ 610.886009] int_signal (arch/x86/kernel/entry_64.S:804)
[ 610.886009] Code: 66 66 66 90 55 48 89 e5 e8 02 ff ff ff 5d c3 66 66 66 66 90 55 48 89 e5 48 83 ec 20 48 89 5d e8 48 89 fb 4c 89 65 f0 4c 89 6d f8 <48> 83 3f 00 74 4e 4c 8d 6f 08 49 89 f4 4c 89 ef e8 4f 85 2a 03
[ 610.886009] RIP mpol_shared_policy_lookup (mm/mempolicy.c:2202)
[ 610.886009] RSP <ffff880291125e48>
[ 610.886009] CR2: ffffffffffffff48
Thanks,
Sasha
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: mm: shmem: NULL ptr deref in shmem_fault
2014-05-12 14:26 ` Sasha Levin
@ 2014-05-12 21:12 ` Andrew Morton
-1 siblings, 0 replies; 12+ messages in thread
From: Andrew Morton @ 2014-05-12 21:12 UTC (permalink / raw)
To: Sasha Levin; +Cc: Hugh Dickins, Dave Jones, linux-mm, LKML, Al Viro
On Mon, 12 May 2014 10:26:17 -0400 Sasha Levin <sasha.levin@oracle.com> 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 flags in mapping_gfp_mask().
>
> [ 4431.615828] BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
> [ 4431.617708] IP: shmem_fault (mm/shmem.c:2960 mm/shmem.c:1236)
> [ 4431.621711] PGD 1d7fb5067 PUD 1d7fb4067 PMD 0
> [ 4431.621945] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> [ 4431.621945] Dumping ftrace buffer:
> [ 4431.621945] (ftrace buffer empty)
> [ 4431.621945] Modules linked in:
> [ 4431.621945] CPU: 1 PID: 20571 Comm: trinity-c61 Not tainted 3.15.0-rc5-next-20140512-sasha-00019-ga20bc00-dirty #456
> [ 4431.621945] task: ffff8803333e0000 ti: ffff88032b562000 task.ti: ffff88032b562000
> [ 4431.621945] RIP: shmem_fault (mm/shmem.c:2960 mm/shmem.c:1236)
> [ 4431.621945] RSP: 0018:ffff88032b5639b8 EFLAGS: 00010296
> [ 4431.621945] RAX: ffff88005daab100 RBX: ffff88005db19e00 RCX: 0000000000000001
> [ 4431.621945] RDX: 0000000000000001 RSI: ffff88032b5639f8 RDI: 0000000000000000
> [ 4431.621945] RBP: ffff88032b5639d8 R08: ffff88032b563a70 R09: ffff88032b5639c4
> [ 4431.621945] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8801caad2ed0
> [ 4431.621945] R13: ffff8801ca27c7e8 R14: 0000000000000000 R15: ffff88005db19e00
> [ 4431.621945] FS: 00007f8c3b4ef700(0000) GS:ffff88006ec00000(0000) knlGS:0000000000000000
> [ 4431.621945] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 4431.621945] CR2: 0000000000000030 CR3: 00000001d7fb6000 CR4: 00000000000006a0
> [ 4431.621945] DR0: 00000000006df000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 4431.621945] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600
> [ 4431.621945] Stack:
> [ 4431.621945] ffffffff8a2bb583 0000020000000286 ffff88032b563a18 ffff88032b563a70
> [ 4431.621945] ffff88032b563a38 ffffffff8a2b83d9 ffff8801e71f8338 00000000ffffffff
> [ 4431.621945] ffff880300000000 0000000000000001 00007f8c3b4fd000 0000000000000000
> [ 4431.621945] Call Trace:
> [ 4431.621945] ? do_read_fault.isra.40 (mm/memory.c:2882)
> [ 4431.621945] __do_fault (mm/memory.c:2703)
> [ 4431.621945] ? _raw_spin_unlock (arch/x86/include/asm/preempt.h:98 include/linux/spinlock_api_smp.h:152 kernel/locking/spinlock.c:183)
> [ 4431.621945] do_read_fault.isra.40 (mm/memory.c:2883)
> [ 4431.621945] ? get_parent_ip (kernel/sched/core.c:2519)
> [ 4431.621945] ? get_parent_ip (kernel/sched/core.c:2519)
> [ 4431.621945] __handle_mm_fault (mm/memory.c:3021 mm/memory.c:3182 mm/memory.c:3306)
> [ 4431.621945] ? __const_udelay (arch/x86/lib/delay.c:126)
> [ 4431.621945] ? __rcu_read_unlock (kernel/rcu/update.c:97)
> [ 4431.621945] handle_mm_fault (mm/memory.c:3329)
> [ 4431.621945] __get_user_pages (mm/gup.c:281 mm/gup.c:466)
> [ 4431.621945] ? preempt_count_sub (kernel/sched/core.c:2575)
> [ 4431.621945] get_user_pages (mm/gup.c:632)
> [ 4431.621945] get_user_pages_fast (arch/x86/mm/gup.c:394)
> [ 4431.621945] vmsplice_to_pipe (fs/splice.c:1487 fs/splice.c:1607)
> [ 4431.621945] ? page_cache_pipe_buf_release (fs/splice.c:267)
> [ 4431.621945] ? kvm_clock_read (arch/x86/include/asm/preempt.h:90 arch/x86/kernel/kvmclock.c:86)
> [ 4431.621945] ? sched_clock (arch/x86/include/asm/paravirt.h:192 arch/x86/kernel/tsc.c:305)
> [ 4431.621945] ? sched_clock_local (kernel/sched/clock.c:214)
> [ 4431.621945] ? vtime_account_user (kernel/sched/cputime.c:687)
> [ 4431.621945] ? debug_smp_processor_id (lib/smp_processor_id.c:57)
> [ 4431.621945] ? put_lock_stats.isra.12 (arch/x86/include/asm/preempt.h:98 kernel/locking/lockdep.c:254)
> [ 4431.621945] ? vtime_account_user (kernel/sched/cputime.c:687)
> [ 4431.621945] ? get_parent_ip (kernel/sched/core.c:2519)
> [ 4431.621945] ? get_parent_ip (kernel/sched/core.c:2519)
> [ 4431.621945] ? __fget_light (include/linux/rcupdate.h:428 include/linux/fdtable.h:80 fs/file.c:684)
> [ 4431.621945] SyS_vmsplice (fs/splice.c:1650 fs/splice.c:1636)
> [ 4431.621945] tracesys (arch/x86/kernel/entry_64.S:746)
> [ 4431.621945] Code: 66 66 66 90 55 b9 01 00 00 00 48 89 e5 53 48 89 fb 4c 8d 4d ec 48 83 ec 18 c7 45 ec 00 02 00 00 48 8b 87 a0 00 00 00 48 8b 78 20 <48> 8b 57 30 4c 8b 82 48 01 00 00 48 8d 56 18 48 8b 76 08 41 81
> [ 4431.621945] RIP shmem_fault (mm/shmem.c:2960 mm/shmem.c:1236)
> [ 4431.621945] RSP <ffff88032b5639b8>
> [ 4431.621945] CR2: 0000000000000030
OK, how the heck can we get all the way to shmem_fault and then find an
inode with no ->mapping? A race, presumably.
viro has been mucking with the splice code, but I don't see how that
can affect things down here.
Stumped.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: mm: shmem: NULL ptr deref in shmem_fault
@ 2014-05-12 21:12 ` Andrew Morton
0 siblings, 0 replies; 12+ messages in thread
From: Andrew Morton @ 2014-05-12 21:12 UTC (permalink / raw)
To: Sasha Levin; +Cc: Hugh Dickins, Dave Jones, linux-mm, LKML, Al Viro
On Mon, 12 May 2014 10:26:17 -0400 Sasha Levin <sasha.levin@oracle.com> 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 flags in mapping_gfp_mask().
>
> [ 4431.615828] BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
> [ 4431.617708] IP: shmem_fault (mm/shmem.c:2960 mm/shmem.c:1236)
> [ 4431.621711] PGD 1d7fb5067 PUD 1d7fb4067 PMD 0
> [ 4431.621945] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> [ 4431.621945] Dumping ftrace buffer:
> [ 4431.621945] (ftrace buffer empty)
> [ 4431.621945] Modules linked in:
> [ 4431.621945] CPU: 1 PID: 20571 Comm: trinity-c61 Not tainted 3.15.0-rc5-next-20140512-sasha-00019-ga20bc00-dirty #456
> [ 4431.621945] task: ffff8803333e0000 ti: ffff88032b562000 task.ti: ffff88032b562000
> [ 4431.621945] RIP: shmem_fault (mm/shmem.c:2960 mm/shmem.c:1236)
> [ 4431.621945] RSP: 0018:ffff88032b5639b8 EFLAGS: 00010296
> [ 4431.621945] RAX: ffff88005daab100 RBX: ffff88005db19e00 RCX: 0000000000000001
> [ 4431.621945] RDX: 0000000000000001 RSI: ffff88032b5639f8 RDI: 0000000000000000
> [ 4431.621945] RBP: ffff88032b5639d8 R08: ffff88032b563a70 R09: ffff88032b5639c4
> [ 4431.621945] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8801caad2ed0
> [ 4431.621945] R13: ffff8801ca27c7e8 R14: 0000000000000000 R15: ffff88005db19e00
> [ 4431.621945] FS: 00007f8c3b4ef700(0000) GS:ffff88006ec00000(0000) knlGS:0000000000000000
> [ 4431.621945] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 4431.621945] CR2: 0000000000000030 CR3: 00000001d7fb6000 CR4: 00000000000006a0
> [ 4431.621945] DR0: 00000000006df000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 4431.621945] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600
> [ 4431.621945] Stack:
> [ 4431.621945] ffffffff8a2bb583 0000020000000286 ffff88032b563a18 ffff88032b563a70
> [ 4431.621945] ffff88032b563a38 ffffffff8a2b83d9 ffff8801e71f8338 00000000ffffffff
> [ 4431.621945] ffff880300000000 0000000000000001 00007f8c3b4fd000 0000000000000000
> [ 4431.621945] Call Trace:
> [ 4431.621945] ? do_read_fault.isra.40 (mm/memory.c:2882)
> [ 4431.621945] __do_fault (mm/memory.c:2703)
> [ 4431.621945] ? _raw_spin_unlock (arch/x86/include/asm/preempt.h:98 include/linux/spinlock_api_smp.h:152 kernel/locking/spinlock.c:183)
> [ 4431.621945] do_read_fault.isra.40 (mm/memory.c:2883)
> [ 4431.621945] ? get_parent_ip (kernel/sched/core.c:2519)
> [ 4431.621945] ? get_parent_ip (kernel/sched/core.c:2519)
> [ 4431.621945] __handle_mm_fault (mm/memory.c:3021 mm/memory.c:3182 mm/memory.c:3306)
> [ 4431.621945] ? __const_udelay (arch/x86/lib/delay.c:126)
> [ 4431.621945] ? __rcu_read_unlock (kernel/rcu/update.c:97)
> [ 4431.621945] handle_mm_fault (mm/memory.c:3329)
> [ 4431.621945] __get_user_pages (mm/gup.c:281 mm/gup.c:466)
> [ 4431.621945] ? preempt_count_sub (kernel/sched/core.c:2575)
> [ 4431.621945] get_user_pages (mm/gup.c:632)
> [ 4431.621945] get_user_pages_fast (arch/x86/mm/gup.c:394)
> [ 4431.621945] vmsplice_to_pipe (fs/splice.c:1487 fs/splice.c:1607)
> [ 4431.621945] ? page_cache_pipe_buf_release (fs/splice.c:267)
> [ 4431.621945] ? kvm_clock_read (arch/x86/include/asm/preempt.h:90 arch/x86/kernel/kvmclock.c:86)
> [ 4431.621945] ? sched_clock (arch/x86/include/asm/paravirt.h:192 arch/x86/kernel/tsc.c:305)
> [ 4431.621945] ? sched_clock_local (kernel/sched/clock.c:214)
> [ 4431.621945] ? vtime_account_user (kernel/sched/cputime.c:687)
> [ 4431.621945] ? debug_smp_processor_id (lib/smp_processor_id.c:57)
> [ 4431.621945] ? put_lock_stats.isra.12 (arch/x86/include/asm/preempt.h:98 kernel/locking/lockdep.c:254)
> [ 4431.621945] ? vtime_account_user (kernel/sched/cputime.c:687)
> [ 4431.621945] ? get_parent_ip (kernel/sched/core.c:2519)
> [ 4431.621945] ? get_parent_ip (kernel/sched/core.c:2519)
> [ 4431.621945] ? __fget_light (include/linux/rcupdate.h:428 include/linux/fdtable.h:80 fs/file.c:684)
> [ 4431.621945] SyS_vmsplice (fs/splice.c:1650 fs/splice.c:1636)
> [ 4431.621945] tracesys (arch/x86/kernel/entry_64.S:746)
> [ 4431.621945] Code: 66 66 66 90 55 b9 01 00 00 00 48 89 e5 53 48 89 fb 4c 8d 4d ec 48 83 ec 18 c7 45 ec 00 02 00 00 48 8b 87 a0 00 00 00 48 8b 78 20 <48> 8b 57 30 4c 8b 82 48 01 00 00 48 8d 56 18 48 8b 76 08 41 81
> [ 4431.621945] RIP shmem_fault (mm/shmem.c:2960 mm/shmem.c:1236)
> [ 4431.621945] RSP <ffff88032b5639b8>
> [ 4431.621945] CR2: 0000000000000030
OK, how the heck can we get all the way to shmem_fault and then find an
inode with no ->mapping? A race, presumably.
viro has been mucking with the splice code, but I don't see how that
can affect things down here.
Stumped.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: mm: shmem: NULL ptr deref in shmem_fault
2014-05-12 21:12 ` Andrew Morton
@ 2014-05-12 21:15 ` Sasha Levin
-1 siblings, 0 replies; 12+ messages in thread
From: Sasha Levin @ 2014-05-12 21:15 UTC (permalink / raw)
To: Andrew Morton; +Cc: Hugh Dickins, Dave Jones, linux-mm, LKML, Al Viro
On 05/12/2014 05:12 PM, Andrew Morton wrote:
> On Mon, 12 May 2014 10:26:17 -0400 Sasha Levin <sasha.levin@oracle.com> 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 flags in mapping_gfp_mask().
>>
>> [ 4431.615828] BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
>> [ 4431.617708] IP: shmem_fault (mm/shmem.c:2960 mm/shmem.c:1236)
>> [ 4431.621711] PGD 1d7fb5067 PUD 1d7fb4067 PMD 0
>> [ 4431.621945] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
>> [ 4431.621945] Dumping ftrace buffer:
>> [ 4431.621945] (ftrace buffer empty)
>> [ 4431.621945] Modules linked in:
>> [ 4431.621945] CPU: 1 PID: 20571 Comm: trinity-c61 Not tainted 3.15.0-rc5-next-20140512-sasha-00019-ga20bc00-dirty #456
>> [ 4431.621945] task: ffff8803333e0000 ti: ffff88032b562000 task.ti: ffff88032b562000
>> [ 4431.621945] RIP: shmem_fault (mm/shmem.c:2960 mm/shmem.c:1236)
>> [ 4431.621945] RSP: 0018:ffff88032b5639b8 EFLAGS: 00010296
>> [ 4431.621945] RAX: ffff88005daab100 RBX: ffff88005db19e00 RCX: 0000000000000001
>> [ 4431.621945] RDX: 0000000000000001 RSI: ffff88032b5639f8 RDI: 0000000000000000
>> [ 4431.621945] RBP: ffff88032b5639d8 R08: ffff88032b563a70 R09: ffff88032b5639c4
>> [ 4431.621945] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8801caad2ed0
>> [ 4431.621945] R13: ffff8801ca27c7e8 R14: 0000000000000000 R15: ffff88005db19e00
>> [ 4431.621945] FS: 00007f8c3b4ef700(0000) GS:ffff88006ec00000(0000) knlGS:0000000000000000
>> [ 4431.621945] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>> [ 4431.621945] CR2: 0000000000000030 CR3: 00000001d7fb6000 CR4: 00000000000006a0
>> [ 4431.621945] DR0: 00000000006df000 DR1: 0000000000000000 DR2: 0000000000000000
>> [ 4431.621945] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600
>> [ 4431.621945] Stack:
>> [ 4431.621945] ffffffff8a2bb583 0000020000000286 ffff88032b563a18 ffff88032b563a70
>> [ 4431.621945] ffff88032b563a38 ffffffff8a2b83d9 ffff8801e71f8338 00000000ffffffff
>> [ 4431.621945] ffff880300000000 0000000000000001 00007f8c3b4fd000 0000000000000000
>> [ 4431.621945] Call Trace:
>> [ 4431.621945] ? do_read_fault.isra.40 (mm/memory.c:2882)
>> [ 4431.621945] __do_fault (mm/memory.c:2703)
>> [ 4431.621945] ? _raw_spin_unlock (arch/x86/include/asm/preempt.h:98 include/linux/spinlock_api_smp.h:152 kernel/locking/spinlock.c:183)
>> [ 4431.621945] do_read_fault.isra.40 (mm/memory.c:2883)
>> [ 4431.621945] ? get_parent_ip (kernel/sched/core.c:2519)
>> [ 4431.621945] ? get_parent_ip (kernel/sched/core.c:2519)
>> [ 4431.621945] __handle_mm_fault (mm/memory.c:3021 mm/memory.c:3182 mm/memory.c:3306)
>> [ 4431.621945] ? __const_udelay (arch/x86/lib/delay.c:126)
>> [ 4431.621945] ? __rcu_read_unlock (kernel/rcu/update.c:97)
>> [ 4431.621945] handle_mm_fault (mm/memory.c:3329)
>> [ 4431.621945] __get_user_pages (mm/gup.c:281 mm/gup.c:466)
>> [ 4431.621945] ? preempt_count_sub (kernel/sched/core.c:2575)
>> [ 4431.621945] get_user_pages (mm/gup.c:632)
>> [ 4431.621945] get_user_pages_fast (arch/x86/mm/gup.c:394)
>> [ 4431.621945] vmsplice_to_pipe (fs/splice.c:1487 fs/splice.c:1607)
>> [ 4431.621945] ? page_cache_pipe_buf_release (fs/splice.c:267)
>> [ 4431.621945] ? kvm_clock_read (arch/x86/include/asm/preempt.h:90 arch/x86/kernel/kvmclock.c:86)
>> [ 4431.621945] ? sched_clock (arch/x86/include/asm/paravirt.h:192 arch/x86/kernel/tsc.c:305)
>> [ 4431.621945] ? sched_clock_local (kernel/sched/clock.c:214)
>> [ 4431.621945] ? vtime_account_user (kernel/sched/cputime.c:687)
>> [ 4431.621945] ? debug_smp_processor_id (lib/smp_processor_id.c:57)
>> [ 4431.621945] ? put_lock_stats.isra.12 (arch/x86/include/asm/preempt.h:98 kernel/locking/lockdep.c:254)
>> [ 4431.621945] ? vtime_account_user (kernel/sched/cputime.c:687)
>> [ 4431.621945] ? get_parent_ip (kernel/sched/core.c:2519)
>> [ 4431.621945] ? get_parent_ip (kernel/sched/core.c:2519)
>> [ 4431.621945] ? __fget_light (include/linux/rcupdate.h:428 include/linux/fdtable.h:80 fs/file.c:684)
>> [ 4431.621945] SyS_vmsplice (fs/splice.c:1650 fs/splice.c:1636)
>> [ 4431.621945] tracesys (arch/x86/kernel/entry_64.S:746)
>> [ 4431.621945] Code: 66 66 66 90 55 b9 01 00 00 00 48 89 e5 53 48 89 fb 4c 8d 4d ec 48 83 ec 18 c7 45 ec 00 02 00 00 48 8b 87 a0 00 00 00 48 8b 78 20 <48> 8b 57 30 4c 8b 82 48 01 00 00 48 8d 56 18 48 8b 76 08 41 81
>> [ 4431.621945] RIP shmem_fault (mm/shmem.c:2960 mm/shmem.c:1236)
>> [ 4431.621945] RSP <ffff88032b5639b8>
>> [ 4431.621945] CR2: 0000000000000030
>
> OK, how the heck can we get all the way to shmem_fault and then find an
> inode with no ->mapping? A race, presumably.
>
> viro has been mucking with the splice code, but I don't see how that
> can affect things down here.
>
> Stumped.
>
There seems to be a race issue with files going away unexpectedly (ignore
me blaming perf):
https://lkml.org/lkml/2014/5/12/514
Can it possibly be the same bug?
Thanks,
Sasha
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: mm: shmem: NULL ptr deref in shmem_fault
@ 2014-05-12 21:15 ` Sasha Levin
0 siblings, 0 replies; 12+ messages in thread
From: Sasha Levin @ 2014-05-12 21:15 UTC (permalink / raw)
To: Andrew Morton; +Cc: Hugh Dickins, Dave Jones, linux-mm, LKML, Al Viro
On 05/12/2014 05:12 PM, Andrew Morton wrote:
> On Mon, 12 May 2014 10:26:17 -0400 Sasha Levin <sasha.levin@oracle.com> 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 flags in mapping_gfp_mask().
>>
>> [ 4431.615828] BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
>> [ 4431.617708] IP: shmem_fault (mm/shmem.c:2960 mm/shmem.c:1236)
>> [ 4431.621711] PGD 1d7fb5067 PUD 1d7fb4067 PMD 0
>> [ 4431.621945] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
>> [ 4431.621945] Dumping ftrace buffer:
>> [ 4431.621945] (ftrace buffer empty)
>> [ 4431.621945] Modules linked in:
>> [ 4431.621945] CPU: 1 PID: 20571 Comm: trinity-c61 Not tainted 3.15.0-rc5-next-20140512-sasha-00019-ga20bc00-dirty #456
>> [ 4431.621945] task: ffff8803333e0000 ti: ffff88032b562000 task.ti: ffff88032b562000
>> [ 4431.621945] RIP: shmem_fault (mm/shmem.c:2960 mm/shmem.c:1236)
>> [ 4431.621945] RSP: 0018:ffff88032b5639b8 EFLAGS: 00010296
>> [ 4431.621945] RAX: ffff88005daab100 RBX: ffff88005db19e00 RCX: 0000000000000001
>> [ 4431.621945] RDX: 0000000000000001 RSI: ffff88032b5639f8 RDI: 0000000000000000
>> [ 4431.621945] RBP: ffff88032b5639d8 R08: ffff88032b563a70 R09: ffff88032b5639c4
>> [ 4431.621945] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8801caad2ed0
>> [ 4431.621945] R13: ffff8801ca27c7e8 R14: 0000000000000000 R15: ffff88005db19e00
>> [ 4431.621945] FS: 00007f8c3b4ef700(0000) GS:ffff88006ec00000(0000) knlGS:0000000000000000
>> [ 4431.621945] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>> [ 4431.621945] CR2: 0000000000000030 CR3: 00000001d7fb6000 CR4: 00000000000006a0
>> [ 4431.621945] DR0: 00000000006df000 DR1: 0000000000000000 DR2: 0000000000000000
>> [ 4431.621945] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600
>> [ 4431.621945] Stack:
>> [ 4431.621945] ffffffff8a2bb583 0000020000000286 ffff88032b563a18 ffff88032b563a70
>> [ 4431.621945] ffff88032b563a38 ffffffff8a2b83d9 ffff8801e71f8338 00000000ffffffff
>> [ 4431.621945] ffff880300000000 0000000000000001 00007f8c3b4fd000 0000000000000000
>> [ 4431.621945] Call Trace:
>> [ 4431.621945] ? do_read_fault.isra.40 (mm/memory.c:2882)
>> [ 4431.621945] __do_fault (mm/memory.c:2703)
>> [ 4431.621945] ? _raw_spin_unlock (arch/x86/include/asm/preempt.h:98 include/linux/spinlock_api_smp.h:152 kernel/locking/spinlock.c:183)
>> [ 4431.621945] do_read_fault.isra.40 (mm/memory.c:2883)
>> [ 4431.621945] ? get_parent_ip (kernel/sched/core.c:2519)
>> [ 4431.621945] ? get_parent_ip (kernel/sched/core.c:2519)
>> [ 4431.621945] __handle_mm_fault (mm/memory.c:3021 mm/memory.c:3182 mm/memory.c:3306)
>> [ 4431.621945] ? __const_udelay (arch/x86/lib/delay.c:126)
>> [ 4431.621945] ? __rcu_read_unlock (kernel/rcu/update.c:97)
>> [ 4431.621945] handle_mm_fault (mm/memory.c:3329)
>> [ 4431.621945] __get_user_pages (mm/gup.c:281 mm/gup.c:466)
>> [ 4431.621945] ? preempt_count_sub (kernel/sched/core.c:2575)
>> [ 4431.621945] get_user_pages (mm/gup.c:632)
>> [ 4431.621945] get_user_pages_fast (arch/x86/mm/gup.c:394)
>> [ 4431.621945] vmsplice_to_pipe (fs/splice.c:1487 fs/splice.c:1607)
>> [ 4431.621945] ? page_cache_pipe_buf_release (fs/splice.c:267)
>> [ 4431.621945] ? kvm_clock_read (arch/x86/include/asm/preempt.h:90 arch/x86/kernel/kvmclock.c:86)
>> [ 4431.621945] ? sched_clock (arch/x86/include/asm/paravirt.h:192 arch/x86/kernel/tsc.c:305)
>> [ 4431.621945] ? sched_clock_local (kernel/sched/clock.c:214)
>> [ 4431.621945] ? vtime_account_user (kernel/sched/cputime.c:687)
>> [ 4431.621945] ? debug_smp_processor_id (lib/smp_processor_id.c:57)
>> [ 4431.621945] ? put_lock_stats.isra.12 (arch/x86/include/asm/preempt.h:98 kernel/locking/lockdep.c:254)
>> [ 4431.621945] ? vtime_account_user (kernel/sched/cputime.c:687)
>> [ 4431.621945] ? get_parent_ip (kernel/sched/core.c:2519)
>> [ 4431.621945] ? get_parent_ip (kernel/sched/core.c:2519)
>> [ 4431.621945] ? __fget_light (include/linux/rcupdate.h:428 include/linux/fdtable.h:80 fs/file.c:684)
>> [ 4431.621945] SyS_vmsplice (fs/splice.c:1650 fs/splice.c:1636)
>> [ 4431.621945] tracesys (arch/x86/kernel/entry_64.S:746)
>> [ 4431.621945] Code: 66 66 66 90 55 b9 01 00 00 00 48 89 e5 53 48 89 fb 4c 8d 4d ec 48 83 ec 18 c7 45 ec 00 02 00 00 48 8b 87 a0 00 00 00 48 8b 78 20 <48> 8b 57 30 4c 8b 82 48 01 00 00 48 8d 56 18 48 8b 76 08 41 81
>> [ 4431.621945] RIP shmem_fault (mm/shmem.c:2960 mm/shmem.c:1236)
>> [ 4431.621945] RSP <ffff88032b5639b8>
>> [ 4431.621945] CR2: 0000000000000030
>
> OK, how the heck can we get all the way to shmem_fault and then find an
> inode with no ->mapping? A race, presumably.
>
> viro has been mucking with the splice code, but I don't see how that
> can affect things down here.
>
> Stumped.
>
There seems to be a race issue with files going away unexpectedly (ignore
me blaming perf):
https://lkml.org/lkml/2014/5/12/514
Can it possibly be the same bug?
Thanks,
Sasha
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: mm: shmem: NULL ptr deref in shmem_fault
2014-05-12 21:15 ` Sasha Levin
@ 2014-05-13 22:20 ` Hugh Dickins
-1 siblings, 0 replies; 12+ messages in thread
From: Hugh Dickins @ 2014-05-13 22:20 UTC (permalink / raw)
To: Sasha Levin
Cc: Kirill A. Shutemov, Andrew Morton, Dave Jones, linux-mm, LKML,
Al Viro, Peter Zijlstra, Ingo Molnar
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 <sasha.levin@oracle.com> 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 flags in mapping_gfp_mask().
Not quite, I think it's just before that: it's got a NULL inode out of
vma->vm_file->f_inode, and is now trying to use that to get i_mapping.
> >>
> >> [ 4431.615828] BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
> >> [ 4431.617708] IP: shmem_fault (mm/shmem.c:2960 mm/shmem.c:1236)
> >> [ 4431.621711] PGD 1d7fb5067 PUD 1d7fb4067 PMD 0
> >> [ 4431.621945] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> >> [ 4431.621945] Dumping ftrace buffer:
> >> [ 4431.621945] (ftrace buffer empty)
> >> [ 4431.621945] Modules linked in:
> >> [ 4431.621945] CPU: 1 PID: 20571 Comm: trinity-c61 Not tainted 3.15.0-rc5-next-20140512-sasha-00019-ga20bc00-dirty #456
> >> [ 4431.621945] task: ffff8803333e0000 ti: ffff88032b562000 task.ti: ffff88032b562000
> >> [ 4431.621945] RIP: shmem_fault (mm/shmem.c:2960 mm/shmem.c:1236)
> >> [ 4431.621945] RSP: 0018:ffff88032b5639b8 EFLAGS: 00010296
> >> [ 4431.621945] RAX: ffff88005daab100 RBX: ffff88005db19e00 RCX: 0000000000000001
> >> [ 4431.621945] RDX: 0000000000000001 RSI: ffff88032b5639f8 RDI: 0000000000000000
> >> [ 4431.621945] RBP: ffff88032b5639d8 R08: ffff88032b563a70 R09: ffff88032b5639c4
> >> [ 4431.621945] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8801caad2ed0
> >> [ 4431.621945] R13: ffff8801ca27c7e8 R14: 0000000000000000 R15: ffff88005db19e00
> >> [ 4431.621945] FS: 00007f8c3b4ef700(0000) GS:ffff88006ec00000(0000) knlGS:0000000000000000
> >> [ 4431.621945] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> >> [ 4431.621945] CR2: 0000000000000030 CR3: 00000001d7fb6000 CR4: 00000000000006a0
> >> [ 4431.621945] DR0: 00000000006df000 DR1: 0000000000000000 DR2: 0000000000000000
> >> [ 4431.621945] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600
> >> [ 4431.621945] Stack:
> >> [ 4431.621945] ffffffff8a2bb583 0000020000000286 ffff88032b563a18 ffff88032b563a70
> >> [ 4431.621945] ffff88032b563a38 ffffffff8a2b83d9 ffff8801e71f8338 00000000ffffffff
> >> [ 4431.621945] ffff880300000000 0000000000000001 00007f8c3b4fd000 0000000000000000
> >> [ 4431.621945] Call Trace:
> >> [ 4431.621945] ? do_read_fault.isra.40 (mm/memory.c:2882)
> >> [ 4431.621945] __do_fault (mm/memory.c:2703)
> >> [ 4431.621945] ? _raw_spin_unlock (arch/x86/include/asm/preempt.h:98 include/linux/spinlock_api_smp.h:152 kernel/locking/spinlock.c:183)
> >> [ 4431.621945] do_read_fault.isra.40 (mm/memory.c:2883)
> >> [ 4431.621945] ? get_parent_ip (kernel/sched/core.c:2519)
> >> [ 4431.621945] ? get_parent_ip (kernel/sched/core.c:2519)
> >> [ 4431.621945] __handle_mm_fault (mm/memory.c:3021 mm/memory.c:3182 mm/memory.c:3306)
> >> [ 4431.621945] ? __const_udelay (arch/x86/lib/delay.c:126)
> >> [ 4431.621945] ? __rcu_read_unlock (kernel/rcu/update.c:97)
> >> [ 4431.621945] handle_mm_fault (mm/memory.c:3329)
> >> [ 4431.621945] __get_user_pages (mm/gup.c:281 mm/gup.c:466)
> >> [ 4431.621945] ? preempt_count_sub (kernel/sched/core.c:2575)
> >> [ 4431.621945] get_user_pages (mm/gup.c:632)
> >> [ 4431.621945] get_user_pages_fast (arch/x86/mm/gup.c:394)
> >> [ 4431.621945] vmsplice_to_pipe (fs/splice.c:1487 fs/splice.c:1607)
> >> [ 4431.621945] ? page_cache_pipe_buf_release (fs/splice.c:267)
> >> [ 4431.621945] ? kvm_clock_read (arch/x86/include/asm/preempt.h:90 arch/x86/kernel/kvmclock.c:86)
> >> [ 4431.621945] ? sched_clock (arch/x86/include/asm/paravirt.h:192 arch/x86/kernel/tsc.c:305)
> >> [ 4431.621945] ? sched_clock_local (kernel/sched/clock.c:214)
> >> [ 4431.621945] ? vtime_account_user (kernel/sched/cputime.c:687)
> >> [ 4431.621945] ? debug_smp_processor_id (lib/smp_processor_id.c:57)
> >> [ 4431.621945] ? put_lock_stats.isra.12 (arch/x86/include/asm/preempt.h:98 kernel/locking/lockdep.c:254)
> >> [ 4431.621945] ? vtime_account_user (kernel/sched/cputime.c:687)
> >> [ 4431.621945] ? get_parent_ip (kernel/sched/core.c:2519)
> >> [ 4431.621945] ? get_parent_ip (kernel/sched/core.c:2519)
> >> [ 4431.621945] ? __fget_light (include/linux/rcupdate.h:428 include/linux/fdtable.h:80 fs/file.c:684)
> >> [ 4431.621945] SyS_vmsplice (fs/splice.c:1650 fs/splice.c:1636)
> >> [ 4431.621945] tracesys (arch/x86/kernel/entry_64.S:746)
> >> [ 4431.621945] Code: 66 66 66 90 55 b9 01 00 00 00 48 89 e5 53 48 89 fb 4c 8d 4d ec 48 83 ec 18 c7 45 ec 00 02 00 00 48 8b 87 a0 00 00 00 48 8b 78 20 <48> 8b 57 30 4c 8b 82 48 01 00 00 48 8d 56 18 48 8b 76 08 41 81
> >> [ 4431.621945] RIP shmem_fault (mm/shmem.c:2960 mm/shmem.c:1236)
> >> [ 4431.621945] RSP <ffff88032b5639b8>
> >> [ 4431.621945] CR2: 0000000000000030
> >
> > OK, how the heck can we get all the way to shmem_fault and then find an
> > inode with no ->mapping? A race, presumably.
> >
> > viro has been mucking with the splice code, but I don't see how that
> > can affect things down here.
> >
> > Stumped.
> >
And the second dump you sent was kernel paging request at ffffffffffffff48
in mpol_shared_policy_lookup(). I don't have your exact config, but I
expect that if you disassemble your shmem_get_policy(), you'll find it
subtracting 0xb8 from inode pointer to locate &SHMEM_I(inode)->policy.
Not that I'll care if it's not exactly 0xb8: we have no particular
reason to expect NULL f_inode once struct file has been freed.
>
> There seems to be a race issue with files going away unexpectedly (ignore
> me blaming perf):
>
> https://lkml.org/lkml/2014/5/12/514
>
> Can it possibly be the same bug?
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... Kirill.
Just guessing, but we know how fond trinity is of remap_file_pages(),
and comparing old and new emulations shows that interesting
struct file *file = get_file(vma->vm_file);
addr = mmap_region(...);
fput(file);
in mm/fremap.c's old emulation, but no get_file() and fput() around
the do_mmap_pgoff() in mm/mmap.c's new emulation.
Before it puts in the new, do_mmap_pgoff() might unmap the last reference
to vma->vm_file, so emulation needs to take its own reference. I'm not
sure how that plays out nowadays with Al's deferred fput, but it does
look suspicious to me.
Hugh
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: mm: shmem: NULL ptr deref in shmem_fault
@ 2014-05-13 22:20 ` Hugh Dickins
0 siblings, 0 replies; 12+ messages in thread
From: Hugh Dickins @ 2014-05-13 22:20 UTC (permalink / raw)
To: Sasha Levin
Cc: Kirill A. Shutemov, Andrew Morton, Dave Jones, linux-mm, LKML,
Al Viro, Peter Zijlstra, Ingo Molnar
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 <sasha.levin@oracle.com> 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 flags in mapping_gfp_mask().
Not quite, I think it's just before that: it's got a NULL inode out of
vma->vm_file->f_inode, and is now trying to use that to get i_mapping.
> >>
> >> [ 4431.615828] BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
> >> [ 4431.617708] IP: shmem_fault (mm/shmem.c:2960 mm/shmem.c:1236)
> >> [ 4431.621711] PGD 1d7fb5067 PUD 1d7fb4067 PMD 0
> >> [ 4431.621945] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> >> [ 4431.621945] Dumping ftrace buffer:
> >> [ 4431.621945] (ftrace buffer empty)
> >> [ 4431.621945] Modules linked in:
> >> [ 4431.621945] CPU: 1 PID: 20571 Comm: trinity-c61 Not tainted 3.15.0-rc5-next-20140512-sasha-00019-ga20bc00-dirty #456
> >> [ 4431.621945] task: ffff8803333e0000 ti: ffff88032b562000 task.ti: ffff88032b562000
> >> [ 4431.621945] RIP: shmem_fault (mm/shmem.c:2960 mm/shmem.c:1236)
> >> [ 4431.621945] RSP: 0018:ffff88032b5639b8 EFLAGS: 00010296
> >> [ 4431.621945] RAX: ffff88005daab100 RBX: ffff88005db19e00 RCX: 0000000000000001
> >> [ 4431.621945] RDX: 0000000000000001 RSI: ffff88032b5639f8 RDI: 0000000000000000
> >> [ 4431.621945] RBP: ffff88032b5639d8 R08: ffff88032b563a70 R09: ffff88032b5639c4
> >> [ 4431.621945] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8801caad2ed0
> >> [ 4431.621945] R13: ffff8801ca27c7e8 R14: 0000000000000000 R15: ffff88005db19e00
> >> [ 4431.621945] FS: 00007f8c3b4ef700(0000) GS:ffff88006ec00000(0000) knlGS:0000000000000000
> >> [ 4431.621945] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> >> [ 4431.621945] CR2: 0000000000000030 CR3: 00000001d7fb6000 CR4: 00000000000006a0
> >> [ 4431.621945] DR0: 00000000006df000 DR1: 0000000000000000 DR2: 0000000000000000
> >> [ 4431.621945] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600
> >> [ 4431.621945] Stack:
> >> [ 4431.621945] ffffffff8a2bb583 0000020000000286 ffff88032b563a18 ffff88032b563a70
> >> [ 4431.621945] ffff88032b563a38 ffffffff8a2b83d9 ffff8801e71f8338 00000000ffffffff
> >> [ 4431.621945] ffff880300000000 0000000000000001 00007f8c3b4fd000 0000000000000000
> >> [ 4431.621945] Call Trace:
> >> [ 4431.621945] ? do_read_fault.isra.40 (mm/memory.c:2882)
> >> [ 4431.621945] __do_fault (mm/memory.c:2703)
> >> [ 4431.621945] ? _raw_spin_unlock (arch/x86/include/asm/preempt.h:98 include/linux/spinlock_api_smp.h:152 kernel/locking/spinlock.c:183)
> >> [ 4431.621945] do_read_fault.isra.40 (mm/memory.c:2883)
> >> [ 4431.621945] ? get_parent_ip (kernel/sched/core.c:2519)
> >> [ 4431.621945] ? get_parent_ip (kernel/sched/core.c:2519)
> >> [ 4431.621945] __handle_mm_fault (mm/memory.c:3021 mm/memory.c:3182 mm/memory.c:3306)
> >> [ 4431.621945] ? __const_udelay (arch/x86/lib/delay.c:126)
> >> [ 4431.621945] ? __rcu_read_unlock (kernel/rcu/update.c:97)
> >> [ 4431.621945] handle_mm_fault (mm/memory.c:3329)
> >> [ 4431.621945] __get_user_pages (mm/gup.c:281 mm/gup.c:466)
> >> [ 4431.621945] ? preempt_count_sub (kernel/sched/core.c:2575)
> >> [ 4431.621945] get_user_pages (mm/gup.c:632)
> >> [ 4431.621945] get_user_pages_fast (arch/x86/mm/gup.c:394)
> >> [ 4431.621945] vmsplice_to_pipe (fs/splice.c:1487 fs/splice.c:1607)
> >> [ 4431.621945] ? page_cache_pipe_buf_release (fs/splice.c:267)
> >> [ 4431.621945] ? kvm_clock_read (arch/x86/include/asm/preempt.h:90 arch/x86/kernel/kvmclock.c:86)
> >> [ 4431.621945] ? sched_clock (arch/x86/include/asm/paravirt.h:192 arch/x86/kernel/tsc.c:305)
> >> [ 4431.621945] ? sched_clock_local (kernel/sched/clock.c:214)
> >> [ 4431.621945] ? vtime_account_user (kernel/sched/cputime.c:687)
> >> [ 4431.621945] ? debug_smp_processor_id (lib/smp_processor_id.c:57)
> >> [ 4431.621945] ? put_lock_stats.isra.12 (arch/x86/include/asm/preempt.h:98 kernel/locking/lockdep.c:254)
> >> [ 4431.621945] ? vtime_account_user (kernel/sched/cputime.c:687)
> >> [ 4431.621945] ? get_parent_ip (kernel/sched/core.c:2519)
> >> [ 4431.621945] ? get_parent_ip (kernel/sched/core.c:2519)
> >> [ 4431.621945] ? __fget_light (include/linux/rcupdate.h:428 include/linux/fdtable.h:80 fs/file.c:684)
> >> [ 4431.621945] SyS_vmsplice (fs/splice.c:1650 fs/splice.c:1636)
> >> [ 4431.621945] tracesys (arch/x86/kernel/entry_64.S:746)
> >> [ 4431.621945] Code: 66 66 66 90 55 b9 01 00 00 00 48 89 e5 53 48 89 fb 4c 8d 4d ec 48 83 ec 18 c7 45 ec 00 02 00 00 48 8b 87 a0 00 00 00 48 8b 78 20 <48> 8b 57 30 4c 8b 82 48 01 00 00 48 8d 56 18 48 8b 76 08 41 81
> >> [ 4431.621945] RIP shmem_fault (mm/shmem.c:2960 mm/shmem.c:1236)
> >> [ 4431.621945] RSP <ffff88032b5639b8>
> >> [ 4431.621945] CR2: 0000000000000030
> >
> > OK, how the heck can we get all the way to shmem_fault and then find an
> > inode with no ->mapping? A race, presumably.
> >
> > viro has been mucking with the splice code, but I don't see how that
> > can affect things down here.
> >
> > Stumped.
> >
And the second dump you sent was kernel paging request at ffffffffffffff48
in mpol_shared_policy_lookup(). I don't have your exact config, but I
expect that if you disassemble your shmem_get_policy(), you'll find it
subtracting 0xb8 from inode pointer to locate &SHMEM_I(inode)->policy.
Not that I'll care if it's not exactly 0xb8: we have no particular
reason to expect NULL f_inode once struct file has been freed.
>
> There seems to be a race issue with files going away unexpectedly (ignore
> me blaming perf):
>
> https://lkml.org/lkml/2014/5/12/514
>
> Can it possibly be the same bug?
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... Kirill.
Just guessing, but we know how fond trinity is of remap_file_pages(),
and comparing old and new emulations shows that interesting
struct file *file = get_file(vma->vm_file);
addr = mmap_region(...);
fput(file);
in mm/fremap.c's old emulation, but no get_file() and fput() around
the do_mmap_pgoff() in mm/mmap.c's new emulation.
Before it puts in the new, do_mmap_pgoff() might unmap the last reference
to vma->vm_file, so emulation needs to take its own reference. I'm not
sure how that plays out nowadays with Al's deferred fput, but it does
look suspicious to me.
Hugh
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: mm: shmem: NULL ptr deref in shmem_fault
2014-05-13 22:20 ` Hugh Dickins
@ 2014-05-14 3:24 ` Sasha Levin
-1 siblings, 0 replies; 12+ messages in thread
From: Sasha Levin @ 2014-05-14 3:24 UTC (permalink / raw)
To: Hugh Dickins
Cc: Kirill A. Shutemov, Andrew Morton, Dave Jones, linux-mm, LKML,
Al Viro, Peter Zijlstra, Ingo Molnar
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... Kirill.
>
> Just guessing, but we know how fond trinity is of remap_file_pages(),
> and comparing old and new emulations shows that interesting
>
> struct file *file = get_file(vma->vm_file);
> addr = mmap_region(...);
> fput(file);
>
> in mm/fremap.c's old emulation, but no get_file() and fput() around
> the do_mmap_pgoff() in mm/mmap.c's new emulation.
>
> Before it puts in the new, do_mmap_pgoff() might unmap the last reference
> to vma->vm_file, so emulation needs to take its own reference. I'm not
> sure how that plays out nowadays with Al's deferred fput, but it does
> look suspicious to me.
I've tested it by reverting the remap_file_pages() patch, and the problem
seems to have disappeared.
Then, I've added it back again, wrapping the do_mmap_pgoff() call with
get_file() and fput(), and the problem is still gone.
Seems like that was the issue all along. I'll send a patch...
Thanks,
Sasha
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: mm: shmem: NULL ptr deref in shmem_fault
@ 2014-05-14 3:24 ` Sasha Levin
0 siblings, 0 replies; 12+ messages in thread
From: Sasha Levin @ 2014-05-14 3:24 UTC (permalink / raw)
To: Hugh Dickins
Cc: Kirill A. Shutemov, Andrew Morton, Dave Jones, linux-mm, LKML,
Al Viro, Peter Zijlstra, Ingo Molnar
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... Kirill.
>
> Just guessing, but we know how fond trinity is of remap_file_pages(),
> and comparing old and new emulations shows that interesting
>
> struct file *file = get_file(vma->vm_file);
> addr = mmap_region(...);
> fput(file);
>
> in mm/fremap.c's old emulation, but no get_file() and fput() around
> the do_mmap_pgoff() in mm/mmap.c's new emulation.
>
> Before it puts in the new, do_mmap_pgoff() might unmap the last reference
> to vma->vm_file, so emulation needs to take its own reference. I'm not
> sure how that plays out nowadays with Al's deferred fput, but it does
> look suspicious to me.
I've tested it by reverting the remap_file_pages() patch, and the problem
seems to have disappeared.
Then, I've added it back again, wrapping the do_mmap_pgoff() call with
get_file() and fput(), and the problem is still gone.
Seems like that was the issue all along. I'll send a patch...
Thanks,
Sasha
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2014-05-14 3:25 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-05-12 14:26 mm: shmem: NULL ptr deref in shmem_fault Sasha Levin
2014-05-12 14:26 ` Sasha Levin
2014-05-12 14:58 ` Sasha Levin
2014-05-12 14:58 ` Sasha Levin
2014-05-12 21:12 ` Andrew Morton
2014-05-12 21:12 ` Andrew Morton
2014-05-12 21:15 ` Sasha Levin
2014-05-12 21:15 ` Sasha Levin
2014-05-13 22:20 ` Hugh Dickins
2014-05-13 22:20 ` Hugh Dickins
2014-05-14 3:24 ` Sasha Levin
2014-05-14 3:24 ` Sasha Levin
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.