linux-kernel - Re: general protection fault in string

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: <20171211230305.GA48753@gmail.com>
Date:   Mon, 11 Dec 2017 15:03:05 -0800
From:   Eric Biggers <ebiggers3@...il.com>
To:     syzbot 
        <bot+f7b85b77fd8042059586165494cd708475e87fc3@...kaller.appspotmail.com>
Cc:     linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        syzkaller-bugs@...glegroups.com, viro@...iv.linux.org.uk,
        tglx@...utronix.de
Subject: Re: general protection fault in string

[+Cc tglx@...utronix.de ]

On Sat, Dec 02, 2017 at 09:10:01PM -0800, syzbot wrote:
> syzkaller has found reproducer for the following crash on
> 2db767d9889cef087149a5eaa35c1497671fa40f
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
> 
> 
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault: 0000 [#1] SMP KASAN
> Dumping ftrace buffer:
>    (ftrace buffer empty)
> Modules linked in:
> CPU: 0 PID: 3075 Comm: syzkaller531375 Not tainted 4.15.0-rc1+ #205
> Hardware name: Google Google Compute Engine/Google Compute Engine,
> BIOS Google 01/01/2011
> task: 00000000523f1e90 task.stack: 00000000c2d38485
> RIP: 0010:string+0xb4/0x200 lib/vsprintf.c:595
> RSP: 0018:ffff8801cc637868 EFLAGS: 00010006
> RAX: dffffc0000000000 RBX: fffffffffffffffe RCX: ffffffff85135fbf
> RDX: 06c7240eabebe406 RSI: 1ffff100398c6f01 RDI: ffff8801cc637888
> RBP: ffff8801cc6378b8 R08: ffffed00398a5566 R09: ffffed00398a5566
> R10: 0000000000000002 R11: ffffed00398a5565 R12: 363920755f5f2034
> R13: 363920755f5f2033 R14: ffffffffffffffff R15: ffff8801cc52ab2a
> FS:  0000000001a75880(0000) GS:ffff8801db400000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00000000205e2ff0 CR3: 00000001cc470000 CR4: 00000000001406f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
>  vsnprintf+0x863/0x1900 lib/vsprintf.c:2282
>  seq_vprintf+0xe3/0x1a0 fs/seq_file.c:397
>  seq_printf+0xb3/0xe0 fs/seq_file.c:412
>  show_timer+0x1ee/0x2b0 fs/proc/base.c:2274
>  seq_read+0x385/0x13d0 fs/seq_file.c:234
>  do_loop_readv_writev fs/read_write.c:673 [inline]
>  do_iter_read+0x3db/0x5b0 fs/read_write.c:897
>  vfs_readv+0x121/0x1c0 fs/read_write.c:959
>  do_preadv+0x11b/0x1a0 fs/read_write.c:1043
>  SYSC_preadv fs/read_write.c:1093 [inline]
>  SyS_preadv+0x30/0x40 fs/read_write.c:1088
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0x440149
> RSP: 002b:00007fff96d72b08 EFLAGS: 00000213 ORIG_RAX: 0000000000000127
> RAX: ffffffffffffffda RBX: 00007fff96d72b10 RCX: 0000000000440149
> RDX: 0000000000000001 RSI: 00000000205e2ff0 RDI: 0000000000000003
> RBP: 0000000000000000 R08: 0000000000000011 R09: 65732f636f72702f
> R10: 0000000000000000 R11: 0000000000000213 R12: 0000000000401a10
> R13: 0000000000401aa0 R14: 0000000000000000 R15: 0000000000000000
> Code: 01 00 00 e8 7f 98 5c fc 4d 85 f6 0f 84 10 01 00 00 e8 71 98 5c
> fc 4c 89 ea 48 b8 00 00 00 00 00 fc ff df 4d 8d 65 01 48 c1 ea 03
> <0f> b6 04 02 4c 89 ea 83 e2 07 38 d0 7f 08 84 c0 0f 85 ec 00 00
> RIP: string+0xb4/0x200 lib/vsprintf.c:595 RSP: ffff8801cc637868
> ---[ end trace 3570c98033660e3f ]---

The bug is that sys_timer_create() allows setting ->it_sigev_notify to almost
any value, but show_timer() assumes that it has one of a specific set of values.
Here's a simplified reproducer:

	#include <fcntl.h>
	#include <signal.h>
	#include <time.h>
	#include <unistd.h>

	int main()
	{
		struct sigevent e = {
			.sigev_signo = 0x1c,
			.sigev_notify = 0x100000,
		};
		timer_t t;
		int fd;
		char buf[64];

		timer_create(CLOCK_MONOTONIC, &e, &t);

		fd = open("/proc/self/timers", O_RDONLY);

		read(fd, buf, sizeof(buf));
	}

I wonder if anything would break if we made sys_timer_create() return -EINVAL
for unrecognized values of sigev_notify?  That's what it *should* do, but it
seems to be the classic "unchecked flags" bug, yet again...

Eric