linux-kernel - Re: fs: use after free in /proc/pid/mountinfo

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.02.1407031434470.10658@chino.kir.corp.google.com>
Date:	Thu, 3 Jul 2014 14:37:12 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Sasha Levin <sasha.levin@...cle.com>
cc:	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Al Viro <viro@...iv.linux.org.uk>, Jan Kara <jack@...e.cz>,
	Dave Jones <davej@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Heiko Carstens <heiko.carstens@...ibm.com>
Subject: Re: fs: use after free in /proc/pid/mountinfo

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/