Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1335969 > unrolled thread

Re: fs: NULL deref in atime_needs_update

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: fs: NULL deref in atime_needs_update Mickaël Salaün <mic@digikod.net> - 2016-02-17 02:00 +0100
    Re: fs: NULL deref in atime_needs_update Dmitry Vyukov <dvyukov@google.com> - 2016-02-19 20:40 +0100
      Re: fs: NULL deref in atime_needs_update Al Viro <viro@ZenIV.linux.org.uk> - 2016-02-20 04:30 +0100
        Re: fs: NULL deref in atime_needs_update Al Viro <viro@ZenIV.linux.org.uk> - 2016-02-20 05:00 +0100
          Re: fs: NULL deref in atime_needs_update Mickaël Salaün <mic@digikod.net> - 2016-02-20 17:00 +0100
            Re: fs: NULL deref in atime_needs_update Al Viro <viro@ZenIV.linux.org.uk> - 2016-02-20 18:20 +0100
              Re: fs: NULL deref in atime_needs_update Al Viro <viro@ZenIV.linux.org.uk> - 2016-02-20 22:00 +0100
              Re: fs: NULL deref in atime_needs_update Mickaël Salaün <mic@digikod.net> - 2016-02-20 22:10 +0100
              Re: fs: NULL deref in atime_needs_update Dmitry Vyukov <dvyukov@google.com> - 2016-02-22 12:30 +0100
                Re: fs: NULL deref in atime_needs_update Al Viro <viro@ZenIV.linux.org.uk> - 2016-02-22 18:30 +0100
        Re: fs: NULL deref in atime_needs_update Dmitry Vyukov <dvyukov@google.com> - 2016-02-20 11:40 +0100

#1335969 — Re: fs: NULL deref in atime_needs_update

[Multipart message — attachments visible in raw view] — view raw

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
> 

[toc] | [next] | [standalone]

#1338425

On Wed, Feb 17, 2016 at 12:40 AM, Mickaël Salaün <mic@digikod.net> 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.

[toc] | [prev] | [next] | [standalone]

#1338624

On Fri, Feb 19, 2016 at 08:32:10PM +0100, Dmitry Vyukov wrote:
> > BUG: unable to handle kernel NULL pointer dereference at 0000000000000050

NULL inode->i_sb, by the look of the offset, but I really don't understand
where the hell is that code doing (or how is that instruction going to
generate dereferencing of 0x50, for that matter).

> 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>

What was the fault address here and what config are you using for those
builds?

[toc] | [prev] | [next] | [standalone]

#1338628

On Sat, Feb 20, 2016 at 03:21:27AM +0000, Al Viro wrote:
> On Fri, Feb 19, 2016 at 08:32:10PM +0100, Dmitry Vyukov wrote:
> > > BUG: unable to handle kernel NULL pointer dereference at 0000000000000050
> 
> NULL inode->i_sb, by the look of the offset, but I really don't understand
> where the hell is that code doing (or how is that instruction going to
> generate dereferencing of 0x50, for that matter).

BTW, Mickaël's trace *does* make sense and it's definitely NULL inode->i_sb
(inode itself - in %rsi, inode->i_sb - in %rdx, offset of s_flags is 0x50,
the line in question is
        if ((inode->i_sb->s_flags & MS_NODIRATIME) && S_ISDIR(inode->i_mode))

What I don't understand is what could possibly have NULL ->i_sb in *any*
instance of struct inode.

[toc] | [prev] | [next] | [standalone]

#1338743

[Multipart message — attachments visible in raw view] — view raw

On 20/02/2016 04:54, Al Viro wrote:
> On Sat, Feb 20, 2016 at 03:21:27AM +0000, Al Viro wrote:
>> On Fri, Feb 19, 2016 at 08:32:10PM +0100, Dmitry Vyukov wrote:
>>>> BUG: unable to handle kernel NULL pointer dereference at 0000000000000050
>>
>> NULL inode->i_sb, by the look of the offset, but I really don't understand
>> where the hell is that code doing (or how is that instruction going to
>> generate dereferencing of 0x50, for that matter).
> 
> BTW, Mickaël's trace *does* make sense and it's definitely NULL inode->i_sb
> (inode itself - in %rsi, inode->i_sb - in %rdx, offset of s_flags is 0x50,
> the line in question is
>         if ((inode->i_sb->s_flags & MS_NODIRATIME) && S_ISDIR(inode->i_mode))
> 
> What I don't understand is what could possibly have NULL ->i_sb in *any*
> instance of struct inode.
> 

I can also trigger bugs with a bad inode pointer dereference in atime_needs_update: if (inode->i_flags & S_NOATIME)

I think the bug may be somewhere in the nd->depth handling (when its value is 0) in fs/namei.c:get_link(): struct saved *last = nd->stack + nd->depth - 1

Moreover, is it intentional that touch_atime() is called by get_link() even if the access (previously checked with security_file_open(), e.g. by do_last) is denied?

[toc] | [prev] | [next] | [standalone]

#1338750

On Sat, Feb 20, 2016 at 02:25:40PM +0100, Mickaël Salaün wrote:

> I think the bug may be somewhere in the nd->depth handling (when its value is 0) in fs/namei.c:get_link(): struct saved *last = nd->stack + nd->depth - 1

Getting there with nd->depth == 0 would certainly be a bug - it would mean
that we got there without should_follow_link() having returned 1.

In case of open() it would be "do_last() has returned positive without
should_follow_link() having returned 1".

<looks>

OK, there are several places where we rely on not getting bogus return values
- inode_permission() should not return positives, neither should vfs_open(),
security_path_truncate() and notify_change().

Other similar "handle the last component" functions are guaranteed to
never return positives other than directly from should_follow_link(), so
they are OK.

IIRC, you used LSM to inject a positive value to inode_permission(), right?

Another way to trigger that would've been ->open() returning positive -
a bug on *anything* since ->open() had been introduced in 0.95.  Amount of
harm would vary - e.g. 0.95 would simply have that positive number returned
to userland, looking like successful open(2).  With no new descriptor, of
course...

Short-term we probably want just
	if (unlikely(error > 0)) {
		WARN_ON(1);
		error = -EINVAL;
	}
added right after out: in do_last(), try to trigger Dmitry's reproducers
on it and then work back to the source of that thing *if* that's what's
happening in his case.  Yours almost certainly is just that.

Longer-term... I'm not sure.  Having a method that is supposed to return 0
or -E<something> actually return positive is going to be a bad thing, no
matter what, but "that bogus value gets passed to userland" is a lot
more tolerable than "kernel memory corruption".  do_last() calling conventions
make it vulnerable to the latter, and as far as nd->stack underruns that's
it, but I'm not sure we don't have other places where such bug in driver,
etc. would translate into mess ;-/

OK, in any case, let's start with checking if Dmitry is seeing that and not
something else.  I still don't understand his stack traces - the fault
address quoted in his first posting doesn't match the register values in
the same trace, and there's also a possibility that it's an RCU-related
crap.  This should give a warning and prevent an oops if we are hitting
a stack underrun on bogus positive from do_last().  Dmitry, could you try
to build with delta below and run your reproducer(s)?

diff --git a/fs/namei.c b/fs/namei.c
index f624d13..e30deef 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -3273,6 +3273,10 @@ opened:
 			goto exit_fput;
 	}
 out:
+	if (unlikely(error > 0)) {
+		WARN_ON(1);
+		error = -EINVAL;
+	}
 	if (got_write)
 		mnt_drop_write(nd->path.mnt);
 	path_put(&save_parent);

[toc] | [prev] | [next] | [standalone]

#1338788

On Sat, Feb 20, 2016 at 09:26:28PM +0100, Mickaël Salaün wrote:
> > +	if (unlikely(error > 0)) {
> > +		WARN_ON(1);
> > +		error = -EINVAL;
> > +	}
> >  	if (got_write)
> >  		mnt_drop_write(nd->path.mnt);
> >  	path_put(&save_parent);
> > 
> 
> I think your warning patch should be upstreamed to detect such cases :)

I'm not sure whether it's better done there or one step closer to the
source - e.g. telling whether it was bogus ->open() or a bogus LSM hook
(and _which_ bogus LSM hook had it been) would be hard with that location
of test.

It still leaves the question of what's going on in Dmitry's tests - it might
be one of those source or it might be something else entirely; this location
of test would at least tell whether a stack underrun is involved or not...

[toc] | [prev] | [next] | [standalone]

#1338793

[Multipart message — attachments visible in raw view] — view raw

On 20/02/2016 18:10, Al Viro wrote:
> On Sat, Feb 20, 2016 at 02:25:40PM +0100, Mickaël Salaün wrote:
> 
>> I think the bug may be somewhere in the nd->depth handling (when its value is 0) in fs/namei.c:get_link(): struct saved *last = nd->stack + nd->depth - 1
> 
> Getting there with nd->depth == 0 would certainly be a bug - it would mean
> that we got there without should_follow_link() having returned 1.
> 
> In case of open() it would be "do_last() has returned positive without
> should_follow_link() having returned 1".

OK, the do_last() return value was the origin of my bug in fs/namei.c:path_openat(): while (!(error = link_path_walk(s, nd)) && (error = do_last(nd, file, op, &opened)) > 0)

> 
> <looks>
> 
> OK, there are several places where we rely on not getting bogus return values
> - inode_permission() should not return positives, neither should vfs_open(),
> security_path_truncate() and notify_change().
> 
> Other similar "handle the last component" functions are guaranteed to
> never return positives other than directly from should_follow_link(), so
> they are OK.
> 
> IIRC, you used LSM to inject a positive value to inode_permission(), right?

Yes, my test hook was wrong because it returned 1 (instead of -EPERM or -EACCES) which is an invalid return value.

> diff --git a/fs/namei.c b/fs/namei.c
> index f624d13..e30deef 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -3273,6 +3273,10 @@ opened:
>  			goto exit_fput;
>  	}
>  out:
> +	if (unlikely(error > 0)) {
> +		WARN_ON(1);
> +		error = -EINVAL;
> +	}
>  	if (got_write)
>  		mnt_drop_write(nd->path.mnt);
>  	path_put(&save_parent);
> 

I think your warning patch should be upstreamed to detect such cases :)

Thanks,
 Mickaël

[toc] | [prev] | [next] | [standalone]

#1339391

On Sat, Feb 20, 2016 at 6:10 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Sat, Feb 20, 2016 at 02:25:40PM +0100, Mickaël Salaün wrote:
>
>> I think the bug may be somewhere in the nd->depth handling (when its value is 0) in fs/namei.c:get_link(): struct saved *last = nd->stack + nd->depth - 1
>
> Getting there with nd->depth == 0 would certainly be a bug - it would mean
> that we got there without should_follow_link() having returned 1.
>
> In case of open() it would be "do_last() has returned positive without
> should_follow_link() having returned 1".
>
> <looks>
>
> OK, there are several places where we rely on not getting bogus return values
> - inode_permission() should not return positives, neither should vfs_open(),
> security_path_truncate() and notify_change().
>
> Other similar "handle the last component" functions are guaranteed to
> never return positives other than directly from should_follow_link(), so
> they are OK.
>
> IIRC, you used LSM to inject a positive value to inode_permission(), right?
>
> Another way to trigger that would've been ->open() returning positive -
> a bug on *anything* since ->open() had been introduced in 0.95.  Amount of
> harm would vary - e.g. 0.95 would simply have that positive number returned
> to userland, looking like successful open(2).  With no new descriptor, of
> course...
>
> Short-term we probably want just
>         if (unlikely(error > 0)) {
>                 WARN_ON(1);
>                 error = -EINVAL;
>         }
> added right after out: in do_last(), try to trigger Dmitry's reproducers
> on it and then work back to the source of that thing *if* that's what's
> happening in his case.  Yours almost certainly is just that.
>
> Longer-term... I'm not sure.  Having a method that is supposed to return 0
> or -E<something> actually return positive is going to be a bad thing, no
> matter what, but "that bogus value gets passed to userland" is a lot
> more tolerable than "kernel memory corruption".  do_last() calling conventions
> make it vulnerable to the latter, and as far as nd->stack underruns that's
> it, but I'm not sure we don't have other places where such bug in driver,
> etc. would translate into mess ;-/
>
> OK, in any case, let's start with checking if Dmitry is seeing that and not
> something else.  I still don't understand his stack traces - the fault
> address quoted in his first posting doesn't match the register values in
> the same trace, and there's also a possibility that it's an RCU-related
> crap.  This should give a warning and prevent an oops if we are hitting
> a stack underrun on bogus positive from do_last().  Dmitry, could you try
> to build with delta below and run your reproducer(s)?
>
> diff --git a/fs/namei.c b/fs/namei.c
> index f624d13..e30deef 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -3273,6 +3273,10 @@ opened:
>                         goto exit_fput;
>         }
>  out:
> +       if (unlikely(error > 0)) {
> +               WARN_ON(1);
> +               error = -EINVAL;
> +       }
>         if (got_write)
>                 mnt_drop_write(nd->path.mnt);
>         path_put(&save_parent);


I've reproduced the second report (the one originating in openat) with
this patch and the WARNING did _not_ fire:


kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
Modules linked in:
CPU: 2 PID: 17525 Comm: syz-executor Not tainted 4.5.0-rc5+ #331
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: ffff88002c6ddf00 ti: ffff88002c740000 task.ti: ffff88002c740000
RIP: 0010:[<ffffffff81821ded>]  [<ffffffff81821ded>]
atime_needs_update+0x2d/0x460
RSP: 0018:ffff88002c747a48  EFLAGS: 00010203
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffff88002c747d88
RDX: 0000000000000001 RSI: 0000000000000000 RDI: 000000000000000c
RBP: ffff88002c747a70 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: ffff88002c747d98
R13: 0000000000000000 R14: ffff88002c747d98 R15: ffff88002c747d78
FS:  00007f24da3d9700(0000) GS:ffff88006d600000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 000000002003f000 CR3: 000000002e2d0000 CR4: 00000000000006e0
Stack:
 ffff88002c747d40 ffff88002c747e08 0000000000000000 ffff88002c747d98
 ffff88002c747d78 ffff88002c747ab8 ffffffff817eeda2 ffff88002c747d78
 ffff880030fa88e8 ffff88002c747c98 0000000000000000 ffff88002c747d40
Call Trace:
 [<     inline     >] get_link fs/namei.c:1006
 [<ffffffff817eeda2>] trailing_symlink+0x142/0x760 fs/namei.c:2094
 [<ffffffff817f5cec>] path_openat+0xb4c/0x5760 fs/namei.c:3393
 [<ffffffff817fe13e>] do_filp_open+0x18e/0x250 fs/namei.c:3425
 [<ffffffff817c2dbc>] do_sys_open+0x1fc/0x420 fs/open.c:1022
 [<     inline     >] SYSC_openat fs/open.c:1049
 [<ffffffff817c3050>] SyS_openat+0x30/0x40 fs/open.c:1043
 [<ffffffff8669f6b6>] 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 98 17 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  [<ffffffff81821ded>] atime_needs_update+0x2d/0x460 fs/inode.c:1617
 RSP <ffff88002c747a48>
---[ end trace 872348222bfe81b0 ]---


This is _not_ on a tmpfs mount.

Regarding the registers, here is disassembly. The crash happens on a
KASAN check of the

ffffffff81821dc0 <atime_needs_update>:
ffffffff81821dc0:       55                      push   %rbp
ffffffff81821dc1:       48 89 e5                mov    %rsp,%rbp
ffffffff81821dc4:       41 57                   push   %r15
ffffffff81821dc6:       41 56                   push   %r14
ffffffff81821dc8:       41 55                   push   %r13
ffffffff81821dca:       41 54                   push   %r12
ffffffff81821dcc:       49 89 fc                mov    %rdi,%r12
ffffffff81821dcf:       53                      push   %rbx
ffffffff81821dd0:       48 89 f3                mov    %rsi,%rbx
ffffffff81821dd3:       e8 98 17 d5 ff          callq
ffffffff81573570 <__sanitizer_cov_trace_pc>
ffffffff81821dd8:       48 8d 7b 0c             lea    0xc(%rbx),%rdi
ffffffff81821ddc:       48 b8 00 00 00 00 00    movabs $0xdffffc0000000000,%rax
ffffffff81821de3:       fc ff df
ffffffff81821de6:       48 89 fa                mov    %rdi,%rdx
ffffffff81821de9:       48 c1 ea 03             shr    $0x3,%rdx
ffffffff81821ded:       0f b6 14 02             movzbl (%rdx,%rax,1),%edx
ffffffff81821df1:       48 89 f8                mov    %rdi,%rax
ffffffff81821df4:       83 e0 07                and    $0x7,%eax
ffffffff81821df7:       83 c0 03                add    $0x3,%eax
ffffffff81821dfa:       38 d0                   cmp    %dl,%al
ffffffff81821dfc:       7c 08                   jl
ffffffff81821e06 <atime_needs_update+0x46>
ffffffff81821dfe:       84 d2                   test   %dl,%dl
ffffffff81821e00:       0f 85 03 03 00 00       jne
ffffffff81822109 <atime_needs_update+0x349>
ffffffff81821e06:       f6 43 0c 02             testb  $0x2,0xc(%rbx)
ffffffff81821e0a:       0f 85 1a 02 00 00       jne
ffffffff8182202a <atime_needs_update+0x26a>
ffffffff81821e10:       e8 5b 17 d5 ff          callq
ffffffff81573570 <__sanitizer_cov_trace_pc>
ffffffff81821e15:       48 8d 7b 28             lea    0x28(%rbx),%rdi
ffffffff81821e19:       48 b8 00 00 00 00 00    movabs $0xdffffc0000000000,%rax
ffffffff81821e20:       fc ff df
ffffffff81821e23:       48 89 fa                mov    %rdi,%rdx
ffffffff81821e26:       48 c1 ea 03             shr    $0x3,%rdx
ffffffff81821e2a:       80 3c 02 00             cmpb   $0x0,(%rdx,%rax,1)
ffffffff81821e2e:       0f 85 c4 03 00 00       jne
ffffffff818221f8 <atime_needs_update+0x438>

It means that inode is NULL here:

bool atime_needs_update(const struct path *path, struct inode *inode)
{
  struct vfsmount *mnt = path->mnt;
  struct timespec now;

  if (inode->i_flags & S_NOATIME)
    return false;

[toc] | [prev] | [next] | [standalone]

#1339746

On Mon, Feb 22, 2016 at 12:20:30PM +0100, Dmitry Vyukov wrote:

> I've reproduced the second report (the one originating in openat) with
> this patch and the WARNING did _not_ fire:

Lovely...  Could you dump your inode.o on anonftp somewhere?  Or post
the disassembled atime_needs_update, for that matter - shouldn't be
all that long...  .config (and gcc version) you are using would also be nice.

On the face of it, NULL inode is a plausible source of that one, but
it's _very_ odd.  It would have to be NULL ->link_inode, and since the
warning hadn't triggered, there was a successful should_follow_link(),
with NULL inode argument.

	Could you slap WARN_ON(!inode) in pick_link()?  Or even
WARN_ON(IS_ERR_OR_NULL(inode)), for that matter...

[toc] | [prev] | [next] | [standalone]

#1338674

On Sat, Feb 20, 2016 at 4:21 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Fri, Feb 19, 2016 at 08:32:10PM +0100, Dmitry Vyukov wrote:
>> > BUG: unable to handle kernel NULL pointer dereference at 0000000000000050
>
> NULL inode->i_sb, by the look of the offset, but I really don't understand
> where the hell is that code doing (or how is that instruction going to
> generate dereferencing of 0x50, for that matter).
>
>> 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>
>
> What was the fault address here and what config are you using for those
> builds?


This is with CONFIG_KASAN. GPF happens on shadow check for NULL
address. In both cases:
RAX: dffffc0000000000
RDX: 0000000000000001
where dffffc0000000000 is shadow base and 0000000000000001 is offset.
So the original memory access was to range [8-16) (i.e. NULL with
small offset).

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web