Re: fs: NULL deref in atime_needs_update

[Dmitry Vyukov]

On Wed, Feb 17, 2016 at 12:40 AM, MickaÃl SalaÃn <mic@xxxxxxxxxxx> wrote:
> 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



I've hit another GPF in atime_needs_update, but this time from SyS_openat:

kasan: GPF could be caused by NULL-ptr deref or user memory
accessgeneral protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
Modules linked in:
CPU: 0 PID: 20147 Comm: syz-executor Not tainted 4.5.0-rc4+ #329
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: ffff88005f154740 ti: ffff88005f048000 task.ti: ffff88005f048000
RIP: 0010:[<ffffffff81818b5d>]  [<ffffffff81818b5d>]
atime_needs_update+0x2d/0x460
RSP: 0018:ffff88005f04fa48  EFLAGS: 00010203
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffff88005f04fd88
RDX: 0000000000000001 RSI: 0000000000000000 RDI: 000000000000000c
RBP: ffff88005f04fa70 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: ffff88005f04fd98
R13: 0000000000000000 R14: ffff88005f04fd98 R15: ffff88005f04fd78
FS:  00007f612639b700(0000) GS:ffff88003ec00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 000000002003ef84 CR3: 000000006073e000 CR4: 00000000000006f0
Stack:
 ffff88005f04fd40 ffff88005f04fe08 0000000000000000 ffff88005f04fd98
 ffff88005f04fd78 ffff88005f04fab8 ffffffff817e5572 ffff88005f04fd78
 ffff88002bcf02f8 0000000000000001 0000000000000000 ffff88002bcf02f8
Call Trace:
 [<     inline     >] get_link fs/namei.c:1006
 [<ffffffff817e5572>] trailing_symlink+0x142/0x760 fs/namei.c:2094
 [<ffffffff817ec531>] path_openat+0xbc1/0x5e30 fs/namei.c:3389
 [<ffffffff817f4fde>] do_filp_open+0x18e/0x250 fs/namei.c:3421
 [<ffffffff817b970c>] do_sys_open+0x1fc/0x420 fs/open.c:1022
 [<     inline     >] SYSC_openat fs/open.c:1049
 [<ffffffff817b99a0>] SyS_openat+0x30/0x40 fs/open.c:1043
 [<ffffffff86662636>] 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 c8 32 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  [<ffffffff81818b5d>] atime_needs_update+0x2d/0x460 fs/inode.c:1611
 RSP <ffff88005f04fa48>
---[ end trace 0790795e3dea8fc8 ]---


The program that triggered it was:

mmap(&(0x7f0000000000)=nil, (0x51000), 0x3, 0x32, 0xffffffffffffffff, 0x0)
mkdir(&(0x7f0000002000)="2e2f66696c653000", 0x40)
mount(&(0x7f000001a000)="2e2f66696c653000",
&(0x7f000001a000+0x4cf)="2e2f66696c653000",
&(0x7f000001a000+0xc79)="72616d667300", 0x800,
&(0x7f000003f000-0x7c)="3dd496054f9a5d4176272c354e968b1cf2c6c18792461e7325b5774e9197aad240b4b45ac67faa72d988a86dd8ba348739259df192d01f08ca39a8524fee967d7f39f0ec53ce000ff78ed4b2510c5ae8812ed421db038390d8f3fea242e682c907334bc6fc74f2490e4aac983bdf85c9f5b6f6b288b0074ab201ab")
r1 = open$dir(&(0x7f000004c000+0x7df)="2e2f66696c653000", 0x200000, 0x82)
symlinkat(&(0x7f000002e000)="2e2f66696c65302f66696c653000", r1,
&(0x7f0000033000)="2e2f66696c653000")
openat(r1, &(0x7f000004b000-0x8)="2e2f66696c653000", 0x40000, 0x2)


On commit 1926e54f115725a9248d0c4c65c22acaf94de4c4.