On Wed, 2 Jul 2014, 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:
> >
> > [ 3569.869749] general protection fault: 0000 [#1] PREEMPT SMP
> > DEBUG_PAGEALLOC
> > [ 3569.869769] Dumping ftrace buffer:
> > [ 3569.869879] (ftrace buffer empty)
> > [ 3569.869894] Modules linked in:
> > [ 3569.869900] CPU: 7 PID: 10239 Comm: trinity-c86 Tainted: G W
> > 3.16.0-rc3-next-20140701-sasha-00023-g4eb2544-dirty #759
> > [ 3569.869906] task: ffff88039e873000 ti: ffff880393f8c000 task.ti:
> > ffff880393f8c000
> > [ 3569.869932] RIP: show_mountinfo (fs/proc_namespace.c:127)
> > [ 3569.869938] RSP: 0018:ffff880393f8fd08 EFLAGS: 00010282
> > [ 3569.869943] RAX: ffff880200c6d208 RBX: 6b6b6b6b6b6b6b03 RCX:
> > 0000000000000074
> > [ 3569.869946] RDX: 0000000000000000 RSI: 6b6b6b6b6b6b6b03 RDI:
> > ffff880200c6d208
> > [ 3569.869953] RBP: ffff880393f8fd58 R08: 0000000000000001 R09:
> > ffff88039e873d38
> > [ 3569.869957] R10: 0000000000000001 R11: 0000000000000000 R12:
> > ffff880200c6d208
> > [ 3569.869962] R13: 6b6b6b6b6b6b6b6b R14: ffff880393f8ff50 R15:
> > ffff880200c6d208
> > [ 3569.869966] FS: 00007f6f20db9700(0000) GS:ffff8801ece00000(0000)
> > knlGS:0000000000000000
> > [ 3569.869969] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [ 3569.869974] CR2: 00007f6f20bee000 CR3: 00000003a0775000 CR4:
> > 00000000000006a0
> > [ 3569.869992] Stack:
> > [ 3569.870011] ffff880393f8ff50 ffff880200c6d208 ffff880393f8fd48
> > ffffffff984e10ea
> > [ 3569.870025] ffffffff9532c7fe ffff8802069a3b80 0000000000000065
> > 6b6b6b6b6b6b6b6b
> > [ 3569.870036] ffff880393f8ff50 ffff880200c6d208 ffff880393f8fd68
> > ffffffff9532c756
> > [ 3569.870038] Call Trace:
> > [ 3569.870051] ? down_read (kernel/locking/rwsem.c:45 (discriminator 2))
> > [ 3569.870059] ? m_start (kernel/module.c:3634)
> > [ 3569.870069] m_show (kernel/module.c:3649)
> > [ 3569.870076] seq_read (fs/seq_file.c:235)
> > [ 3569.870081] ? single_open_size (fs/seq_file.c:166)
> > [ 3569.870092] do_loop_readv_writev (fs/read_write.c:708)
> > [ 3569.870098] ? single_open_size (fs/seq_file.c:166)
> > [ 3569.870098] do_readv_writev (fs/read_write.c:840)
> > [ 3569.870098] ? get_parent_ip (kernel/sched/core.c:2550)
> > [ 3569.870098] ? mutex_lock_nested (./arch/x86/include/asm/preempt.h:98
> > kernel/locking/mutex.c:570 kernel/locking/mutex.c:587)
> > [ 3569.870098] ? __fdget_pos (fs/file.c:714)
> > [ 3569.870098] ? __fdget_pos (fs/file.c:714)
> > [ 3569.870098] ? trace_hardirqs_on_caller (kernel/locking/lockdep.c:2557
> > kernel/locking/lockdep.c:2599)
> > [ 3569.870098] ? __fget_light (fs/file.c:685)
> > [ 3569.870098] vfs_readv (fs/read_write.c:866)
> > [ 3569.870098] SyS_readv (fs/read_write.c:892 fs/read_write.c:884)
> > [ 3569.870098] tracesys (arch/x86/kernel/entry_64.S:542)
> > [ 3569.870098] Code: 00 00 00 00 66 66 66 66 90 55 48 89 e5 48 83 ec 50 48
> > 89 5d d8 48 89 f3 4c 89 65 e0 49 89 fc 4c 89 6d e8 4c 89 75 f0 4c 89 7d f8
> > <48> 8b 06 48 89 75 b0 4c 8b 76 08 8b 96 ec 00 00 00 48 89 45 b8
> > All code
> > ========
> > 0: 00 00 add %al,(%rax)
> > 2: 00 00 add %al,(%rax)
> > 4: 66 66 66 66 90 data32 data32 data32 xchg %ax,%ax
> > 9: 55 push %rbp
> > a: 48 89 e5 mov %rsp,%rbp
> > d: 48 83 ec 50 sub $0x50,%rsp
> > 11: 48 89 5d d8 mov %rbx,-0x28(%rbp)
> > 15: 48 89 f3 mov %rsi,%rbx
> > 18: 4c 89 65 e0 mov %r12,-0x20(%rbp)
> > 1c: 49 89 fc mov %rdi,%r12
> > 1f: 4c 89 6d e8 mov %r13,-0x18(%rbp)
> > 23: 4c 89 75 f0 mov %r14,-0x10(%rbp)
> > 27: 4c 89 7d f8 mov %r15,-0x8(%rbp)
> > 2b:* 48 8b 06 mov (%rsi),%rax <--
> > trapping instruction
> > 2e: 48 89 75 b0 mov %rsi,-0x50(%rbp)
> > 32: 4c 8b 76 08 mov 0x8(%rsi),%r14
> > 36: 8b 96 ec 00 00 00 mov 0xec(%rsi),%edx
> > 3c: 48 89 45 b8 mov %rax,-0x48(%rbp)
Does this now reproduce on Linus's tree? If so, does reverting commit
058504edd026 ("fs/seq_file: fallback to vmalloc allocation") prevent this
issue?
This is a use-after-free since the poison value is 0x6b and I'm presuming
that your /proc/self/mountinfo may be larger than PAGE_SIZE in your
testing environment.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
