general protection fault in show_timer

[syzbot]

Hello,

syzkaller hit the following crash on
43570f0383d6d5879ae585e6c3cf027ba321546f
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.

Unfortunately, I don't have any reproducer for this bug yet.


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: 1 PID: 22618 Comm: syz-executor4 Not tainted 4.15.0-rc1+ #199
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
task: ffff8801c048c400 task.stack: ffff8801cd968000
RIP: 0010:show_timer+0x1c7/0x2b0 fs/proc/base.c:2274
RSP: 0018:ffff8801cd96f9e0 EFLAGS: 00010006
RAX: dffffc0000000000 RBX: ffff8801cff22e40 RCX: ffffffff81ccb88e
RDX: 0000000030a68524 RSI: ffffc90002dea000 RDI: 0000000185342920
RBP: ffff8801cd96fa10 R08: ffffed003a0514c5 R09: ffffed003a0514c5
R10: ffff8801c048c400 R11: ffffed003a0514c4 R12: 0000000040000000
R13: ffff8801c79e7000 R14: ffffffff853419e0 R15: 0000000000000507
FS: 00007f19f811e700(0000) GS:ffff8801db500000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f4ab586bdb8 CR3: 00000001d1788000 CR4: 00000000001426e0
DR0: 0000000020000000 DR1: 0000000020000008 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600
Call Trace:
traverse+0x248/0xa00 fs/seq_file.c:111
seq_read+0x96a/0x13d0 fs/seq_file.c:189
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:0x4529d9
RSP: 002b:00007f19f811dc58 EFLAGS: 00000212 ORIG_RAX: 0000000000000127
RAX: ffffffffffffffda RBX: 00007f19f811d950 RCX: 00000000004529d9
RDX: 0000000000000001 RSI: 00000000205e2ff0 RDI: 0000000000000013
RBP: 00007f19f811d940 R08: 0000000000000000 R09: 0000000000000000
R10: 0001000000000000 R11: 0000000000000212 R12: 00000000004b7346
R13: 00007f19f811dac8 R14: 00000000004b7351 R15: 0000000000000000
Code: 89 c7 4c 0f 44 f1 41 83 e4 fb 4d 63 e4 e8 a2 2f a3 ff 4a 8d 3c e5 20
29 34 85 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00
0f 85 a2 00 00 00 4a 8b 14 e5 20 29 34 85 4c 89 ef
RIP: show_timer+0x1c7/0x2b0 fs/proc/base.c:2274 RSP: ffff8801cd96f9e0
---[ end trace a6bb4fa3405ff530 ]---
Kernel panic - not syncing: Fatal exception
Dumping ftrace buffer:
(ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..


---
This bug is generated by a dumb bot. It may contain errors.
See https://goo.gl/tpsmEJ for details.
Direct all questions to syzk...@googlegroups.com.
Please credit me with: Reported-by: syzbot <syzk...@googlegroups.com>

syzbot will keep track of this bug report.
Once a fix for this bug is committed, please reply to this email with:
#syz fix: exact-commit-title
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug
report.
Note: all commands must start from beginning of the line in the email body.

[Alexey Dobriyan]

On 11/30/17, syzbot
<bot+054c6cd125793643a9...@syzkaller.appspotmail.com>
wrote:

This looks like ASAN problem

ffffffff81a5f1d9: e8 72 74 b7 ff call
ffffffff815d6650 <__sanitizer_cov_trace_pc>
ffffffff81a5f1de: 4a 8d 3c e5 a0 9e b4 lea rdi,[r12*8-0x7b4b6160]
ffffffff81a5f1e5: 84
ffffffff81a5f1e6: 48 b8 00 00 00 00 00 movabs rax,0xdffffc0000000000
ffffffff81a5f1ed: fc ff df
ffffffff81a5f1f0: 48 89 fa mov rdx,rdi
ffffffff81a5f1f3: 48 c1 ea 03 shr rdx,0x3
ffffffff81a5f1f7: 80 3c 02 00 ===>cmp BYTE PTR
[rdx+rax*1],0x0 <====

This is code injected by KASAN_INLINE

timer_show() looks seemingly fine:
"timer" pointer is valid otherwise code would oopsed earlier
tp->ns is valid otherwise it'd oopsed inside pid_nr_ns()

[Dmitry Vyukov]

This is not KASAN bug. Kernel tries to dereference 0x0000000185342920.
Failure mode is just different.

[Dmitry Vyukov]

Looking at code and disass:


seq_printf(m, "notify: %s/%s.%d\n",
ffffffff81ccb88e: 4a 8d 3c e5 20 29 34 lea -0x7acbd6e0(,%r12,8),%rdi
ffffffff81ccb895: 85
ffffffff81ccb896: 48 b8 00 00 00 00 00 movabs $0xdffffc0000000000,%rax
ffffffff81ccb89d: fc ff df
ffffffff81ccb8a0: 48 89 fa mov %rdi,%rdx
ffffffff81ccb8a3: 48 c1 ea 03 shr $0x3,%rdx
ffffffff81ccb8a7: 80 3c 02 00 cmpb $0x0,(%rdx,%rax,1)
ffffffff81ccb8ab: 0f 85 a2 00 00 00 jne
ffffffff81ccb953 <show_timer+0x273>
ffffffff81ccb8b1: 4a 8b 14 e5 20 29 34 mov -0x7acbd6e0(,%r12,8),%rdx
ffffffff81ccb8b8: 85
ffffffff81ccb8b9: 4c 89 ef mov %r13,%rdi
ffffffff81ccb8bc: 45 89 f8 mov %r15d,%r8d
ffffffff81ccb8bf: 4c 89 f1 mov %r14,%rcx
ffffffff81ccb8c2: 48 c7 c6 a0 1a 34 85 mov $0xffffffff85341aa0,%rsi
ffffffff81ccb8c9: e8 22 5c eb ff callq
ffffffff81b814f0 <seq_printf>


static int show_timer(struct seq_file *m, void *v)
{
struct k_itimer *timer;
struct timers_private *tp = m->private;
int notify;
static const char * const nstr[] = {
[SIGEV_SIGNAL] = "signal",
[SIGEV_NONE] = "none",
[SIGEV_THREAD] = "thread",
};

timer = list_entry((struct list_head *)v, struct k_itimer, list);
notify = timer->it_sigev_notify;

seq_printf(m, "ID: %d\n", timer->it_id);
seq_printf(m, "signal: %d/%p\n",
timer->sigq->info.si_signo,
timer->sigq->info.si_value.sival_ptr);
seq_printf(m, "notify: %s/%s.%d\n",
nstr[notify & ~SIGEV_THREAD_ID],
(notify & SIGEV_THREAD_ID) ? "tid" : "pid",
pid_nr_ns(timer->it_pid, tp->ns));
seq_printf(m, "ClockID: %d\n", timer->it_clock);

return 0;
}


it seems that notify is equal to 0x0000000040000000 and this makes
nstr[notify & ~SIGEV_THREAD_ID] a totally wild access.

[Alexey Dobriyan]

[cc security@]
100% oops with interrupts disabled by nobody
or kernel memory read

I'm new to KASAN.

> it seems that notify is equal to 0x0000000040000000 and this makes
> nstr[notify & ~SIGEV_THREAD_ID] a totally wild access.

[nods]
you named the bug already

"notify" directly comes from userspace struct sigevent::sigev_notify
without adult supervision.

Reproducer is timer_create + read(/proc/self/timers)

BUG: unable to handle kernel paging request at 00000000b3695f68
IP: show_timer+0x73/0xa0
PGD 3d18f067 P4D 3d18f067 PUD 0
Oops: 0000 [#1] PREEMPT SMP
CPU: 0 PID: 2819 Comm: a.out Not tainted 4.15.0-rc1-00179-ga0908a1b7d68 #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.10.2-1.fc27 04/01/2014
task: 00000000ea51a5c5 task.stack: 00000000d68c2dbc
RIP: 0010:show_timer+0x73/0xa0
RSP: 0018:ffffc900001bfdd0 EFLAGS: 00010006
RAX: ffffffff814cddbd RBX: 0000000040000000 RCX: ffffffff814cddbd
RDX: 0000000000000000 RSI: ffffffff814d9419 RDI: ffff88003dab9500
RBP: ffff88003dab9500 R08: 0000000000000b03 R09: 0000000000000007
R10: ffffc9000040b908 R11: ffff88003d9ce020 R12: ffff88003c1c6570
R13: ffff88003d514d80 R14: ffff88003dab9500 R15: ffff88003c1c6570
FS: 00007f52624f0700(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000

CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033

CR2: 0000000181414880 CR3: 000000003c243000 CR4: 00000000000006b0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
seq_read+0xe6/0x3b0
__vfs_read+0x1e/0x120
? ptrace_do_notify+0x6a/0x80
vfs_read+0x84/0x110
SyS_read+0x3d/0xa0
do_syscall_64+0x4b/0x180
entry_SYSCALL64_slow_path+0x25/0x25
RIP: 0033:0x7f5261e15fc0
RSP: 002b:00007ffd2f89f5c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f5261e15fc0
RDX: 0000000000001000 RSI: 00007ffd2f89f620 RDI: 0000000000000003
RBP: 0000000000000000 R08: 00007f52620cce40 R09: 00007f5261d47c60
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000400574
R13: 00007ffd2f8a0700 R14: 0000000000000000 R15: 0000000000000000
Code: 89 f1 ff f6 c3 04 48 89 ef 48 c7 c1 c9 44 4c 81 41 89 c0 48 c7
c0 bd dd 4c 81 48 c7 c6 19 94 4d 81 48 0f 44 c8 83 e3 fb 48 63 db <48>
8b 14 dd 80 48 41 81 e8 f0 3b fd ff 41 8b 54 24 30 48 89 ef
RIP: show_timer+0x73/0xa0 RSP: ffffc900001bfdd0
CR2: 0000000181414880
---[ end trace 99049f704e3a24ad ]---
note: a.out[2819] exited with preempt_count 1

[Dmitry Vyukov]

+syzbot back, please don't drop it, it's reading

[Thomas Gleixner]

On Thu, 30 Nov 2017, Alexey Dobriyan wrote:

> [cc security@]
> 100% oops with interrupts disabled by nobody
> or kernel memory read

> [nods]
> you named the bug already
>
> "notify" directly comes from userspace struct sigevent::sigev_notify
> without adult supervision.
>
> Reproducer is timer_create + read(/proc/self/timers)

Bah. That's a really old one.

Tentative fix below. That needs more though but looking at the existing
check there is only one valid combo with SIGEV_THREAD_ID.

Thanks,

tglx

8<----------------
--- a/kernel/time/posix-timers.c
+++ b/kernel/time/posix-timers.c
@@ -434,6 +434,16 @@ static struct pid *good_sigevent(sigeven
{
struct task_struct *rtn = current->group_leader;

+ switch (event->sigev_notify) {
+ case SIGEV_NONE:
+ case SIGEV_SIGNAL:
+ case SIGEV_SIGNAL | SIGEV_THREAD_ID:
+ case SIGEV_THREAD:
+ break;
+ default:
+ return NULL;
+ }
+
if ((event->sigev_notify & SIGEV_THREAD_ID ) &&
(!(rtn = find_task_by_vpid(event->sigev_notify_thread_id)) ||
!same_thread_group(rtn, current) ||

[syzbot]

syzkaller has found reproducer for the following crash on
4131d5166185d0d75b5f1d4bf362a9e0bac05598
git://git.cmpxchg.org/linux-mmots.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: 1 PID: 3084 Comm: syzkaller930220 Not tainted 4.15.0-rc1-mm1+ #29

Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011

task: 00000000ba405a9b task.stack: 00000000c05e4588
RIP: 0010:show_timer+0x1c7/0x2b0 fs/proc/base.c:2303
RSP: 0018:ffff8801cb9b7ac8 EFLAGS: 00010006
RAX: dffffc0000000000 RBX: ffff8801cb8e2e00 RCX: ffffffff81cd3aee
RDX: 0000000050a68705 RSI: ffffffff85f1a780 RDI: 0000000285343828
RBP: ffff8801cb9b7af8 R08: ffffed00397474e5 R09: ffffed00397474e5
R10: ffff8801cc0fc000 R11: ffffed00397474e4 R12: 0000000060000001
R13: ffff8801cbec05c0 R14: ffffffff85342920 R15: 0000000000000c0c
FS: 00000000010b4880(0000) GS:ffff8801db500000(0000) knlGS:0000000000000000

CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033

CR2: 0000000020b15000 CR3: 00000001cb9f7000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
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:0x440159
RSP: 002b:00007ffdfd209348 EFLAGS: 00000217 ORIG_RAX: 0000000000000127
RAX: ffffffffffffffda RBX: 00007ffdfd209350 RCX: 0000000000440159
RDX: 0000000000000001 RSI: 0000000020b15000 RDI: 0000000000000003
RBP: 0000000000000000 R08: 65732f636f72702f R09: 65732f636f72702f
R10: 0000000000000000 R11: 0000000000000217 R12: 0000000000401a20
R13: 0000000000401ab0 R14: 0000000000000000 R15: 0000000000000000
Code: 89 c7 4c 0f 44 f1 41 83 e4 fb 4d 63 e4 e8 c2 00 a3 ff 4a 8d 3c e5 20
38 34 85 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00
0f 85 a2 00 00 00 4a 8b 14 e5 20 38 34 85 4c 89 ef
RIP: show_timer+0x1c7/0x2b0 fs/proc/base.c:2303 RSP: ffff8801cb9b7ac8
---[ end trace 6e3489af1f81e62c ]---

[Thomas Gleixner]

On Sun, 3 Dec 2017, syzbot wrote:

> syzkaller has found reproducer for the following crash on
> 4131d5166185d0d75b5f1d4bf362a9e0bac05598
> git://git.cmpxchg.org/linux-mmots.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

Posted a fix a few days ago after the first report, but never heard back.

https://marc.info/?l=linux-kernel&m=151204669103208&w=2

Thanks,

tglx

[Kees Cook]

FWIW, this looks correct to me.

-Kees

--
Kees Cook
Pixel Security

[Greg KH]

Did this ever go anywhere? I don't see it in Linus's tree yet...

thanks,

greg k-h

[Thomas Gleixner]

I learned yesterday that syzboz is understuffed and cannot test patches, so
I need to find a minute to run the reproducer myself and verify that the
patch is correct.

Thanks,

tglx

[Dmitry Vyukov]

Hi Thomas,

Why do you say so? Have you tried to ask it to test?
https://github.com/google/syzkaller/blob/master/docs/syzbot.md#communication-with-syzbot
What happened?

[Thomas Gleixner]

Eric explained that to me yesterday and I did not try yet.

Thanks,

tglx

[Eric Biggers]

Your patch definitely fixes the bug (I tested the C reproducers, you just need
to build a kernel with CONFIG_CHECKPOINT_RESTORE=y and CONFIG_POSIX_TIMERS=y,
then run them). The real question is whether the check being introduced is too
strict -- are there users passing in other values for ->sigev_notify that would
be broken? That I can't really answer.

Eric

[Thomas Gleixner]

Me neither. The manpage is rather clear about the possible values, so I
don't expect wreckage. Aside of that non canonical values would have to
have bit 2, i.e. SIGEV_THREAD_ID cleared because that already has a
restriction that it's only allowed with SIGEV_SIGNAL. So unlikely...

If really some crap application breaks we can handle it in the default
clause by setting it to SIGEV_SIGNAL. Though I rather prefer not to do that
unless it turns out to be absolutely necessary.

Thanks,

tglx

[Eric Biggers]

I see a fix is committed now (thanks!), so let's tell syzbot:

#syz fix: posix-timer: Properly check sigevent->sigev_notify

[Eric Biggers]