From: "Mickaël Salaün" <mic@digikod.net>
To: Dmitry Vyukov <dvyukov@google.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Cc: syzkaller <syzkaller@googlegroups.com>,
Kostya Serebryany <kcc@google.com>,
Alexander Potapenko <glider@google.com>,
Sasha Levin <sasha.levin@oracle.com>
Subject: Re: fs: NULL deref in atime_needs_update
Date: Wed, 17 Feb 2016 00:40:14 +0100 [thread overview]
Message-ID: <56C3B35E.6020109@digikod.net> (raw)
In-Reply-To: <CACT4Y+ae=DQjrTtwSqm1PJ9rsnRAvKiBkRjBqaQH6f6W1dOh2Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6112 bytes --]
Hi,
Actually I found the same bug (without fuzzing) and I can reproduce it in a deterministic way (e.g. by creating a LSM that return 1 for the security_file_open hook). At least, from v4.2.8 I can easily trigger traces like this :
BUG: unable to handle kernel NULL pointer dereference at 0000000000000050
IP: [<ffffffff81170871>] atime_needs_update+0x11/0xc0
PGD 127b17067 PUD 12ab2e067 PMD 0
Oops: 0000 [#45] SMP
[...]
RIP: 0010:[<ffffffff81170871>] [<ffffffff81170871>] atime_needs_update+0x11/0xc0
RSP: 0018:ffff880127853c18 EFLAGS: 00010246
RAX: ffff88012ad0c080 RBX: ffff88012ad0c1d8 RCX: ffff88012ad0c080
RDX: 0000000000000000 RSI: ffff88012ad0c1d8 RDI: ffff880127853d98
RBP: ffff880127853c28 R08: ffff8800cc0a2540 R09: ffff8800cfbfc320
R10: ffff8800cc0a2540 R11: 0000000000000001 R12: ffff8800cb5d6300
R13: 0000000000000000 R14: ffff88012ad0c080 R15: ffff880127853e7c
FS: 00007f1054aae700(0000) GS:ffff88012fc40000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000050 CR3: 0000000127977000 CR4: 00000000000406e0
Stack:
ffff88012ad0c1d8 ffff8800cb5d6300 ffff880127853c60 ffffffff8117094e
ffff8800c9ade3c0 0000000000000000 00000000a670294f ffff880127853d70
ffff880127853d98 ffff880127853c98 ffffffff8116071c ffff8800cb4ada80
Call Trace:
[<ffffffff8117094e>] ? touch_atime+0x2e/0xd0
[<ffffffff8116071c>] ? trailing_symlink+0xec/0x280
[<ffffffff81163a78>] ? path_openat+0x468/0x1240
[<ffffffff8111856d>] ? pagevec_lru_move_fn+0xed/0x110
[<ffffffff81117ff0>] ? __activate_page+0x130/0x130
[<ffffffff8116593c>] ? do_filp_open+0x8c/0x100
[<ffffffff81164dec>] ? filename_lookup+0xec/0x180
[<ffffffff8115bc24>] ? do_open_execat+0x74/0x170
[<ffffffff8115d437>] ? do_execveat_common.isra.42+0x1a7/0x6a0
[<ffffffff8115db90>] ? SyS_execve+0x30/0x40
[<ffffffff8156ad65>] ? stub_execve+0x5/0x5
[<ffffffff8156aadb>] ? entry_SYSCALL_64_fastpath+0x16/0x6a
Code: 89 c7 e8 63 eb ff ff 48 89 d8 5b c3 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 41 54 53 f6 46 0c 02 75 72 48 8b 56 28 <48> 8b 42 50 a9 01 04 00 00 75 63 f6 c4 08 75 65 4c 8b 27 41 8b
RIP [<ffffffff81170871>] atime_needs_update+0x11/0xc0
RSP <ffff880127853c18>
CR2: 0000000000000050
---[ end trace 97dc4f4bb0214bd8 ]---
Regards,
Mickaël
On 05/02/2016 22:11, Dmitry Vyukov wrote:
> Hello,
>
> I've hit the following GPF while running syzkaller fuzzer:
>
> general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
> Modules linked in:
> CPU: 1 PID: 5178 Comm: syz-executor Not tainted 4.5.0-rc2+ #65
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> task: ffff880064768000 ti: ffff8800622c0000 task.ti: ffff8800622c0000
> RIP: 0010:[<ffffffff8181aa5d>] [<ffffffff8181aa5d>]
> atime_needs_update+0x2d/0x460
> RSP: 0018:ffff8800622c7a30 EFLAGS: 00010203
> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: dffffc0000000000
> RDX: 0000000000000001 RSI: 0000000000000000 RDI: 000000000000000c
> RBP: ffff8800622c7a58 R08: 0000000000000001 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000001 R12: ffff8800622c7c08
> R13: ffff8800622c7c08 R14: ffff8800301ca322 R15: ffff8800622c7bb0
> FS: 00007fd1c9f8b700(0000) GS:ffff88003ed00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 0000000020f31000 CR3: 0000000062274000 CR4: 00000000000006e0
> Stack:
> ffff8800622c7bf4 0000000000000000 ffff8800622c7c08 ffff8800301ca322
> ffff8800622c7bb0 ffff8800622c7b38 ffffffff817ecd91 ffff880030bf5200
> ffff8800622c7bb8 1ffff1000c458f56 ffff8800622c7c00 ffff8800622c7be0
> Call Trace:
> [< inline >] get_link fs/namei.c:1006
> [<ffffffff817ecd91>] link_path_walk+0xaf1/0x1030 fs/namei.c:1968
> [<ffffffff817ed311>] path_parentat+0x41/0x150 fs/namei.c:2176
> [<ffffffff817f4c5c>] filename_parentat+0x17c/0x3c0 fs/namei.c:2198
> [< inline >] user_path_parent fs/namei.c:2412
> [< inline >] SYSC_renameat2 fs/namei.c:4411
> [< inline >] SyS_renameat2 fs/namei.c:4375
> [< inline >] SYSC_renameat fs/namei.c:4521
> [<ffffffff817f9a72>] SyS_renameat+0x192/0x820 fs/namei.c:4518
> [<ffffffff8669e0b6>] entry_SYSCALL_64_fastpath+0x16/0x7a
> arch/x86/entry/entry_64.S:185
> Code: 89 e5 41 57 41 56 41 55 41 54 49 89 fc 53 48 89 f3 e8 08 25 d5
> ff 48 8d 7b 0c 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f>
> b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85
> RIP [<ffffffff8181aa5d>] atime_needs_update+0x2d/0x460 fs/inode.c:1611
> RSP <ffff8800622c7a30>
> ---[ end trace 1a4c9bda4680ce46 ]---
>
> On commit df48ab3c2f5ffca88b7803ffbadd074bd5a0a2ef.
>
> Objdump shows that inode is NULL in atime_needs_update.
>
> Unfortunately reproduction of this crash is very hard. The program
> executes something along the lines of:
>
> mmap(0x20000000, 15945728, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x20000000
> mkdir("./bus", 0662515705056234013740) = 0
> openat(AT_FDCWD, "./bus", O_RDONLY|O_EXCL) = 3
> symlinkat("../bus", 3, "./bus") = 0
> renameat(3, "./bus", 3, "./bus/file0") = 0
> mmap(0x20f35000, 4096, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x20f35000
> mount("./bus", "./bus", 0x20f2aee4,
> MS_RDONLY|MS_NODEV|MS_RELATIME|MS_NODIRATIME|MS_BIND|MS_MOVE|MS_REC|MS_UNBINDABLE|MS_SLAVE|MS_SHARED|0xc000380,
> 0x20093f5f) = 0
> open("./bus/file0", O_RDWR|O_EXCL) = -1 EISDIR (Is a directory)
> exit_group(0) = ?
>
> But in multiple threads so that some calls can be doubled and/or
> overlapped. And all this happens on a tmpfs mount.
>
> But I was able to reproduce it 8 or so times, so I am sure that it is real.
>
> For future reference, I was running these programs:
> https://gist.githubusercontent.com/dvyukov/124c457d308fa724d88a/raw/fec2d86e125a7fd2fa2916791d65d7daead7cbbb/gistfile1.txt
> Following these instructions:
> https://github.com/google/syzkaller/wiki/How-to-execute-syzkaller-programs
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
next prev parent reply other threads:[~2016-02-16 23:40 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-05 21:11 fs: NULL deref in atime_needs_update Dmitry Vyukov
2016-02-16 23:40 ` Mickaël Salaün [this message]
2016-02-19 19:32 ` Dmitry Vyukov
2016-02-20 3:21 ` Al Viro
2016-02-20 3:54 ` Al Viro
2016-02-20 13:25 ` Mickaël Salaün
2016-02-20 17:10 ` Al Viro
2016-02-20 20:26 ` Mickaël Salaün
2016-02-20 20:50 ` Al Viro
2016-02-22 11:20 ` Dmitry Vyukov
2016-02-22 17:23 ` Al Viro
2016-02-23 15:34 ` Dmitry Vyukov
2016-02-23 18:17 ` Al Viro
2016-02-20 10:36 ` Dmitry Vyukov
2016-02-24 3:12 ` Ian Kent
2016-02-24 4:46 ` Al Viro
2016-02-24 10:03 ` Dmitry Vyukov
2016-02-24 10:15 ` Dmitry Vyukov
2016-02-24 13:35 ` Dmitry Vyukov
2016-02-24 15:15 ` Al Viro
2016-02-25 8:29 ` Dmitry Vyukov
2016-02-25 16:39 ` Al Viro
2016-02-26 21:21 ` Al Viro
2016-02-26 21:25 ` Dmitry Vyukov
2016-02-26 22:07 ` Al Viro
2016-02-27 22:27 ` Al Viro
2016-02-28 15:43 ` Dmitry Vyukov
2016-02-28 16:04 ` Dmitry Vyukov
2016-02-28 17:01 ` Al Viro
2016-02-28 20:01 ` Al Viro
2016-02-29 9:38 ` Dmitry Vyukov
2016-02-29 12:34 ` Dmitry Vyukov
2016-02-29 16:11 ` Al Viro
2016-02-29 13:09 ` Al Viro
2016-02-29 15:54 ` Dmitry Vyukov
2016-02-29 16:19 ` Al Viro
2016-02-29 18:19 ` Dmitry Vyukov
2016-03-01 8:59 ` Dmitry Vyukov
2016-02-29 16:45 ` Linus Torvalds
2016-02-29 16:50 ` Al Viro
2016-02-29 17:20 ` Al Viro
2016-02-29 17:24 ` Linus Torvalds
2016-02-29 13:43 ` David Howells
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56C3B35E.6020109@digikod.net \
--to=mic@digikod.net \
--cc=dvyukov@google.com \
--cc=glider@google.com \
--cc=kcc@google.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sasha.levin@oracle.com \
--cc=syzkaller@googlegroups.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).