netdev - RE: netlink executing RO memory

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]
Date:	Fri, 6 Jun 2014 09:02:14 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Sasha Levin' <sasha.levin@...cle.com>,
	"David S. Miller" <davem@...emloft.net>
CC:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Eric Dumazet <eric.dumazet@...il.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: RE: netlink executing RO memory

From: Sasha Levin
> While fuzzing with trinity inside a KVM tools guest running the latest -next
> kernel I've stumbled on the following spew:
> 
> [  306.065161] kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
> [  306.067295] BUG: unable to handle kernel paging request at ffff880053b8fd08
> [  306.069237] IP: 0xffff880053b8fd08  (??:?)
> [  306.070071] PGD 24b9c067 PUD 705dd2067 PMD 705d34067 PTE 8000000053b8f163
> [  306.070071] Oops: 0011 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> [  306.070071] Dumping ftrace buffer:
> [  306.070071]    (ftrace buffer empty)
> [  306.070071] Modules linked in:
> [  306.070071] CPU: 16 PID: 9577 Comm: trinity-c194 Tainted: G        W     3.15.0-rc8-next-20140605-
> sasha-00020-g833a807 #592
> [  306.070071] task: ffff880053b90000 ti: ffff880053b8c000 task.ti: ffff880053b8c000
> [  306.070071] RIP: 0xffff880053b8fd08  (??:?)
> [  306.070071] RSP: 0018:ffff880053b8fcc8  EFLAGS: 00010287
> [  306.070071] RAX: ffff8806286e8000 RBX: 0000000000000000 RCX: 0000004742e748d4
> [  306.070071] RDX: 0000000000000007 RSI: ffffffff9fffd31c RDI: ffffffffa0558ed5
> [  306.070071] RBP: ffff880053b8fd08 R08: 0000000000005d3c R09: 0000000000000000
> [  306.070071] R10: 0000000000000000 R11: 0000000000000001 R12: ffff880053b8fdf8
> [  306.070071] R13: ffff8803d55b8000 R14: ffff88065ea35cd0 R15: 0000000000000000
> [  306.070071] FS:  00007f5c3bb31700(0000) GS:ffff8803d7000000(0000) knlGS:0000000000000000
> [  306.070071] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [  306.070071] CR2: ffff880053b8fd08 CR3: 0000000053b6b000 CR4: 00000000000006a0
> [  306.070071] DR0: 00000000006d6000 DR1: 00000000006d6000 DR2: 0000000000000000
> [  306.070071] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 000000000095060a
> [  306.070071] Stack:
> [  306.070071]  ffff880053b8fdc8 00000000026d7de0 0000000000000010 7fffffffffffffff
> [  306.070071]  0000000000000000 ffff88065ea35cd0 0000000000000001 0000000000000000
> [  306.095047]  ffff880053b8fda8 ffffffffa0000ad1 ffff8803d55b8000 ffff8803d71d8340
> [  306.095047] Call Trace:
> [  306.095047] netlink_sendmsg (net/netlink/af_netlink.c:2398)
> [  306.095047] sock_aio_write (net/socket.c:959 net/socket.c:974)
> [  306.095047] ? sched_clock_local (kernel/sched/clock.c:214)
> [  306.095047] ? vtime_account_user (kernel/sched/cputime.c:687)
> [  306.095047] do_sync_write (fs/read_write.c:458)
> [  306.095047] vfs_write (fs/read_write.c:534)
> [  306.095047] SyS_write (fs/read_write.c:584 fs/read_write.c:576)
> [  306.095047] tracesys (arch/x86/kernel/entry_64.S:542)
> [ 306.095047] Code: 00 00 00 ff ff ff ff ff ff ff 7f 00 00 00 00 00 00 00 00 d0 5c a3 5e 06 88 ff ff
> 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <a8> fd b8 53 00 88 ff ff d1 0a 00 a0 ff ff ff ff 00
> 80 5b d5 03
> All code
> ========
>    0:	00 00                	add    %al,(%rax)
>    2:	00 ff                	add    %bh,%bh
>    4:	ff                   	(bad)
>    5:	ff                   	(bad)
>    6:	ff                   	(bad)
>    7:	ff                   	(bad)
>    8:	ff                   	(bad)
>    9:	ff                   	(bad)
>    a:	7f 00                	jg     0xc
>    c:	00 00                	add    %al,(%rax)
>    e:	00 00                	add    %al,(%rax)
>   10:	00 00                	add    %al,(%rax)
>   12:	00 d0                	add    %dl,%al
>   14:	5c                   	pop    %rsp
>   15:	a3 5e 06 88 ff ff 01 	movabs %eax,0x1ffff88065e
>   1c:	00 00
> 	...
>   2a:*	00 a8 fd b8 53 00    	add    %ch,0x53b8fd(%rax)		<-- trapping instruction
>   30:	88 ff                	mov    %bh,%bh
>   32:	ff d1                	callq  *%rcx
>   34:	0a 00                	or     (%rax),%al
>   36:	a0 ff ff ff ff 00 80 	movabs 0xd55b8000ffffffff,%al
>   3d:	5b d5
>   3f:	03 00                	add    (%rax),%eax

The disassembly hasn't aligned itself with the instruction boundaries.

> Code starting with the faulting instruction
> ===========================================
>    0:	a8 fd                	test   $0xfd,%al
>    2:	b8 53 00 88 ff       	mov    $0xff880053,%eax
>    7:	ff d1                	callq  *%rcx
>    9:	0a 00                	or     (%rax),%al
>    b:	a0 ff ff ff ff 00 80 	movabs 0xd55b8000ffffffff,%al
>   12:	5b d5
>   14:	03 00                	add    (%rax),%eax

And that doesn't look like valid code at all.

The code must have jumped to the instruction - otherwise it would
have faulted on the previous one.

So most likely there was an indirect call from the previous frame.
Note that $rbp also contains the faulting address.

	David



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html