Re: general protection fault in security_inode_getattr

Re: general protection fault in security_inode_getattr

[Ondrej Mosnacek]

On Mon, Aug 24, 2020 at 9:37 PM syzbot
<syzbot+f07cc9be8d1d226947ed@syzkaller.appspotmail.com> wrote:
> syzbot has found a reproducer for the following issue on:

Looping in fsdevel and OverlayFS maintainers, as this seems to be
FS/OverlayFS related...

See also original report against 5.8-rc7:
https://lore.kernel.org/linux-security-module/0000000000008caae305ab9a5318@google.com/T/

>
> HEAD commit:    d012a719 Linux 5.9-rc2
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=14aa130e900000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=891ca5711a9f1650
> dashboard link: https://syzkaller.appspot.com/bug?extid=f07cc9be8d1d226947ed
> compiler:       clang version 10.0.0 (https://github.com/llvm/llvm-project/ c2443155a0fb245c8f17f2c1c72b6ea391e86e81)
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=104a650e900000
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+f07cc9be8d1d226947ed@syzkaller.appspotmail.com
>
> general protection fault, probably for non-canonical address 0xdffffc000000000d: 0000 [#1] PREEMPT SMP KASAN
> KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f]
> CPU: 1 PID: 32288 Comm: syz-executor.3 Not tainted 5.9.0-rc2-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> RIP: 0010:d_backing_inode include/linux/dcache.h:549 [inline]
> RIP: 0010:security_inode_getattr+0x42/0x140 security/security.c:1276
> Code: 1b fe 49 8d 5e 08 48 89 d8 48 c1 e8 03 42 80 3c 38 00 74 08 48 89 df e8 bc b4 5b fe 48 8b 1b 48 83 c3 68 48 89 d8 48 c1 e8 03 <42> 80 3c 38 00 74 08 48 89 df e8 9f b4 5b fe 48 8b 1b 48 83 c3 0c
> RSP: 0018:ffffc9000a017750 EFLAGS: 00010202
> RAX: 000000000000000d RBX: 0000000000000068 RCX: ffff888093ec6180
> RDX: 0000000000000000 RSI: ffffc9000a017860 RDI: ffffc9000a017850
> RBP: ffffc9000a017850 R08: dffffc0000000000 R09: ffffc9000a017850
> R10: fffff52001402f0c R11: 0000000000000000 R12: ffffc9000a017860
> R13: 0000000000008401 R14: ffffc9000a017850 R15: dffffc0000000000
> FS:  00007f292d4ef700(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000001b30920074 CR3: 00000000937fd000 CR4: 00000000001506e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
>  vfs_getattr+0x21/0x60 fs/stat.c:121
>  ovl_copy_up_one fs/overlayfs/copy_up.c:850 [inline]
>  ovl_copy_up_flags+0x2ef/0x2a00 fs/overlayfs/copy_up.c:931
>  ovl_maybe_copy_up+0x154/0x180 fs/overlayfs/copy_up.c:963
>  ovl_open+0xa2/0x200 fs/overlayfs/file.c:147
>  do_dentry_open+0x7c8/0x1010 fs/open.c:817
>  do_open fs/namei.c:3251 [inline]
>  path_openat+0x2794/0x3840 fs/namei.c:3368
>  do_filp_open+0x191/0x3a0 fs/namei.c:3395
>  file_open_name+0x321/0x430 fs/open.c:1113
>  acct_on kernel/acct.c:207 [inline]
>  __do_sys_acct kernel/acct.c:286 [inline]
>  __se_sys_acct+0x122/0x6f0 kernel/acct.c:273
>  do_syscall_64+0x31/0x70 arch/x86/entry/common.c:46
>  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> RIP: 0033:0x45d579
> Code: 5d b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 2b b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007f292d4eec78 EFLAGS: 00000246 ORIG_RAX: 00000000000000a3
> RAX: ffffffffffffffda RBX: 0000000000000700 RCX: 000000000045d579
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000020000040
> RBP: 000000000118cf70 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 000000000118cf4c
> R13: 00007ffc8e04bc4f R14: 00007f292d4ef9c0 R15: 000000000118cf4c
> Modules linked in:
> ---[ end trace 7e4f1041b188e411 ]---
> RIP: 0010:d_backing_inode include/linux/dcache.h:549 [inline]
> RIP: 0010:security_inode_getattr+0x42/0x140 security/security.c:1276
> Code: 1b fe 49 8d 5e 08 48 89 d8 48 c1 e8 03 42 80 3c 38 00 74 08 48 89 df e8 bc b4 5b fe 48 8b 1b 48 83 c3 68 48 89 d8 48 c1 e8 03 <42> 80 3c 38 00 74 08 48 89 df e8 9f b4 5b fe 48 8b 1b 48 83 c3 0c
> RSP: 0018:ffffc9000a017750 EFLAGS: 00010202
> RAX: 000000000000000d RBX: 0000000000000068 RCX: ffff888093ec6180
> RDX: 0000000000000000 RSI: ffffc9000a017860 RDI: ffffc9000a017850
> RBP: ffffc9000a017850 R08: dffffc0000000000 R09: ffffc9000a017850
> R10: fffff52001402f0c R11: 0000000000000000 R12: ffffc9000a017860
> R13: 0000000000008401 R14: ffffc9000a017850 R15: dffffc0000000000
> FS:  00007f292d4ef700(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007fef820e7000 CR3: 00000000937fd000 CR4: 00000000001506e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
>

-- 
Ondrej Mosnacek
Software Engineer, Platform Security - SELinux kernel
Red Hat, Inc.

Re: general protection fault in security_inode_getattr

[Miklos Szeredi]

On Mon, Aug 24, 2020 at 11:00 PM Ondrej Mosnacek <omosnace@redhat.com> wrote:
>
> On Mon, Aug 24, 2020 at 9:37 PM syzbot
> <syzbot+f07cc9be8d1d226947ed@syzkaller.appspotmail.com> wrote:
> > syzbot has found a reproducer for the following issue on:
>
> Looping in fsdevel and OverlayFS maintainers, as this seems to be
> FS/OverlayFS related...

Hmm, the oopsing code is always something like:

All code
========
   0: 1b fe                sbb    %esi,%edi
   2: 49 8d 5e 08          lea    0x8(%r14),%rbx
   6: 48 89 d8              mov    %rbx,%rax
   9: 48 c1 e8 03          shr    $0x3,%rax
   d: 42 80 3c 38 00        cmpb   $0x0,(%rax,%r15,1)
  12: 74 08                je     0x1c
  14: 48 89 df              mov    %rbx,%rdi
  17: e8 bc b4 5b fe        callq  0xfffffffffe5bb4d8
  1c: 48 8b 1b              mov    (%rbx),%rbx
  1f: 48 83 c3 68          add    $0x68,%rbx
  23: 48 89 d8              mov    %rbx,%rax
  26: 48 c1 e8 03          shr    $0x3,%rax
  2a:* 42 80 3c 38 00        cmpb   $0x0,(%rax,%r15,1) <-- trapping instruction
  2f: 74 08                je     0x39
  31: 48 89 df              mov    %rbx,%rdi
  34: e8 9f b4 5b fe        callq  0xfffffffffe5bb4d8
  39: 48 8b 1b              mov    (%rbx),%rbx
  3c: 48 83 c3 0c          add    $0xc,%rbx


And that looks (to me) like the unrolled loop in call_int_hook().  I
don't see how that could be related to overlayfs, though it's
definitely interesting why it only triggers from
overlay->vfs_getattr()->security_inode_getattr()...

Thanks,
Miklos

Re: general protection fault in security_inode_getattr

[Dmitry Vyukov]

On Fri, Oct 30, 2020 at 2:02 PM Miklos Szeredi <miklos@szeredi.hu> wrote:
>
> On Mon, Aug 24, 2020 at 11:00 PM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> >
> > On Mon, Aug 24, 2020 at 9:37 PM syzbot
> > <syzbot+f07cc9be8d1d226947ed@syzkaller.appspotmail.com> wrote:
> > > syzbot has found a reproducer for the following issue on:
> >
> > Looping in fsdevel and OverlayFS maintainers, as this seems to be
> > FS/OverlayFS related...
>
> Hmm, the oopsing code is always something like:
>
> All code
> ========
>    0: 1b fe                sbb    %esi,%edi
>    2: 49 8d 5e 08          lea    0x8(%r14),%rbx
>    6: 48 89 d8              mov    %rbx,%rax
>    9: 48 c1 e8 03          shr    $0x3,%rax
>    d: 42 80 3c 38 00        cmpb   $0x0,(%rax,%r15,1)
>   12: 74 08                je     0x1c
>   14: 48 89 df              mov    %rbx,%rdi
>   17: e8 bc b4 5b fe        callq  0xfffffffffe5bb4d8
>   1c: 48 8b 1b              mov    (%rbx),%rbx
>   1f: 48 83 c3 68          add    $0x68,%rbx
>   23: 48 89 d8              mov    %rbx,%rax
>   26: 48 c1 e8 03          shr    $0x3,%rax
>   2a:* 42 80 3c 38 00        cmpb   $0x0,(%rax,%r15,1) <-- trapping instruction
>   2f: 74 08                je     0x39
>   31: 48 89 df              mov    %rbx,%rdi
>   34: e8 9f b4 5b fe        callq  0xfffffffffe5bb4d8
>   39: 48 8b 1b              mov    (%rbx),%rbx
>   3c: 48 83 c3 0c          add    $0xc,%rbx
>
>
> And that looks (to me) like the unrolled loop in call_int_hook().  I
> don't see how that could be related to overlayfs, though it's
> definitely interesting why it only triggers from
> overlay->vfs_getattr()->security_inode_getattr()...


>   26: 48 c1 e8 03          shr    $0x3,%rax
>   2a:* 42 80 3c 38 00        cmpb   $0x0,(%rax,%r15,1) <-- trapping instruction


This access is part of KASAN check. But the original address kernel
tries to access is NULL, so it's not an issue with KASAN.

The line is this:

int security_inode_getattr(const struct path *path)
{
    if (unlikely(IS_PRIVATE(d_backing_inode(path->dentry))))
        return 0;

So it's either path is NULL, or something in d_backing_inode
dereferences NULL path->dentry.

The reproducer does involve overlayfs:

mkdir(&(0x7f0000000240)='./file1\x00', 0x0)
mkdir(&(0x7f0000000300)='./bus\x00', 0x0)
r0 = creat(&(0x7f00000000c0)='./bus/file1\x00', 0x0)
mkdir(&(0x7f0000000080)='./file0\x00', 0x0)
mount$overlay(0x400002, &(0x7f0000000000)='./bus\x00',
&(0x7f0000000100)='overlay\x00', 0x0,
&(0x7f00000003c0)=ANY=[@ANYBLOB='upperdir=./file1,lowerdir=./bus,workdir=./file0,metacopy=on'])
link(&(0x7f0000000200)='./bus/file1\x00', &(0x7f00000002c0)='./bus/file0\x00')
write$RDMA_USER_CM_CMD_RESOLVE_ADDR(r0, 0x0, 0x0)
acct(&(0x7f0000000040)='./bus/file0\x00')

Though, it may be overlayfs-related, or it may be a generic bug that
requires a tricky reproducer and the only reproducer syzbot come up
with happened to involve overlayfs.
But there are 4 reproducers on syzbot dashboard and all of them
involve overlayfs and they are somewhat different. So my bet would be
on overlayfs.

Re: general protection fault in security_inode_getattr

[Miklos Szeredi]

On Fri, Oct 30, 2020 at 7:42 PM Dmitry Vyukov <dvyukov@google.com> wrote:
>
> On Fri, Oct 30, 2020 at 2:02 PM Miklos Szeredi <miklos@szeredi.hu> wrote:
> >
> > On Mon, Aug 24, 2020 at 11:00 PM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> > >
> > > On Mon, Aug 24, 2020 at 9:37 PM syzbot
> > > <syzbot+f07cc9be8d1d226947ed@syzkaller.appspotmail.com> wrote:
> > > > syzbot has found a reproducer for the following issue on:
> > >
> > > Looping in fsdevel and OverlayFS maintainers, as this seems to be
> > > FS/OverlayFS related...
> >
> > Hmm, the oopsing code is always something like:
> >
> > All code
> > ========
> >    0: 1b fe                sbb    %esi,%edi
> >    2: 49 8d 5e 08          lea    0x8(%r14),%rbx
> >    6: 48 89 d8              mov    %rbx,%rax
> >    9: 48 c1 e8 03          shr    $0x3,%rax
> >    d: 42 80 3c 38 00        cmpb   $0x0,(%rax,%r15,1)
> >   12: 74 08                je     0x1c
> >   14: 48 89 df              mov    %rbx,%rdi
> >   17: e8 bc b4 5b fe        callq  0xfffffffffe5bb4d8
> >   1c: 48 8b 1b              mov    (%rbx),%rbx
> >   1f: 48 83 c3 68          add    $0x68,%rbx
> >   23: 48 89 d8              mov    %rbx,%rax
> >   26: 48 c1 e8 03          shr    $0x3,%rax
> >   2a:* 42 80 3c 38 00        cmpb   $0x0,(%rax,%r15,1) <-- trapping instruction
> >   2f: 74 08                je     0x39
> >   31: 48 89 df              mov    %rbx,%rdi
> >   34: e8 9f b4 5b fe        callq  0xfffffffffe5bb4d8
> >   39: 48 8b 1b              mov    (%rbx),%rbx
> >   3c: 48 83 c3 0c          add    $0xc,%rbx
> >
> >
> > And that looks (to me) like the unrolled loop in call_int_hook().  I
> > don't see how that could be related to overlayfs, though it's
> > definitely interesting why it only triggers from
> > overlay->vfs_getattr()->security_inode_getattr()...
>
>
> >   26: 48 c1 e8 03          shr    $0x3,%rax
> >   2a:* 42 80 3c 38 00        cmpb   $0x0,(%rax,%r15,1) <-- trapping instruction
>
>
> This access is part of KASAN check. But the original address kernel
> tries to access is NULL, so it's not an issue with KASAN.
>
> The line is this:
>
> int security_inode_getattr(const struct path *path)
> {
>     if (unlikely(IS_PRIVATE(d_backing_inode(path->dentry))))
>         return 0;
>
> So it's either path is NULL, or something in d_backing_inode
> dereferences NULL path->dentry.
>
> The reproducer does involve overlayfs:
>
> mkdir(&(0x7f0000000240)='./file1\x00', 0x0)
> mkdir(&(0x7f0000000300)='./bus\x00', 0x0)
> r0 = creat(&(0x7f00000000c0)='./bus/file1\x00', 0x0)
> mkdir(&(0x7f0000000080)='./file0\x00', 0x0)
> mount$overlay(0x400002, &(0x7f0000000000)='./bus\x00',
> &(0x7f0000000100)='overlay\x00', 0x0,
> &(0x7f00000003c0)=ANY=[@ANYBLOB='upperdir=./file1,lowerdir=./bus,workdir=./file0,metacopy=on'])
> link(&(0x7f0000000200)='./bus/file1\x00', &(0x7f00000002c0)='./bus/file0\x00')
> write$RDMA_USER_CM_CMD_RESOLVE_ADDR(r0, 0x0, 0x0)
> acct(&(0x7f0000000040)='./bus/file0\x00')
>
> Though, it may be overlayfs-related, or it may be a generic bug that
> requires a tricky reproducer and the only reproducer syzbot come up
> with happened to involve overlayfs.
> But there are 4 reproducers on syzbot dashboard and all of them
> involve overlayfs and they are somewhat different. So my bet would be
> on overlayfs.

Seems there's no C reproducer, though.   Can this be reproduced
without KASAN obfuscating the oops?

Thanks,
Miklos

Re: general protection fault in security_inode_getattr

[Dmitry Vyukov]

On Fri, Oct 30, 2020 at 8:21 PM Miklos Szeredi <miklos@szeredi.hu> wrote:
> > > On Mon, Aug 24, 2020 at 11:00 PM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> > > >
> > > > On Mon, Aug 24, 2020 at 9:37 PM syzbot
> > > > <syzbot+f07cc9be8d1d226947ed@syzkaller.appspotmail.com> wrote:
> > > > > syzbot has found a reproducer for the following issue on:
> > > >
> > > > Looping in fsdevel and OverlayFS maintainers, as this seems to be
> > > > FS/OverlayFS related...
> > >
> > > Hmm, the oopsing code is always something like:
> > >
> > > All code
> > > ========
> > >    0: 1b fe                sbb    %esi,%edi
> > >    2: 49 8d 5e 08          lea    0x8(%r14),%rbx
> > >    6: 48 89 d8              mov    %rbx,%rax
> > >    9: 48 c1 e8 03          shr    $0x3,%rax
> > >    d: 42 80 3c 38 00        cmpb   $0x0,(%rax,%r15,1)
> > >   12: 74 08                je     0x1c
> > >   14: 48 89 df              mov    %rbx,%rdi
> > >   17: e8 bc b4 5b fe        callq  0xfffffffffe5bb4d8
> > >   1c: 48 8b 1b              mov    (%rbx),%rbx
> > >   1f: 48 83 c3 68          add    $0x68,%rbx
> > >   23: 48 89 d8              mov    %rbx,%rax
> > >   26: 48 c1 e8 03          shr    $0x3,%rax
> > >   2a:* 42 80 3c 38 00        cmpb   $0x0,(%rax,%r15,1) <-- trapping instruction
> > >   2f: 74 08                je     0x39
> > >   31: 48 89 df              mov    %rbx,%rdi
> > >   34: e8 9f b4 5b fe        callq  0xfffffffffe5bb4d8
> > >   39: 48 8b 1b              mov    (%rbx),%rbx
> > >   3c: 48 83 c3 0c          add    $0xc,%rbx
> > >
> > >
> > > And that looks (to me) like the unrolled loop in call_int_hook().  I
> > > don't see how that could be related to overlayfs, though it's
> > > definitely interesting why it only triggers from
> > > overlay->vfs_getattr()->security_inode_getattr()...
> >
> >
> > >   26: 48 c1 e8 03          shr    $0x3,%rax
> > >   2a:* 42 80 3c 38 00        cmpb   $0x0,(%rax,%r15,1) <-- trapping instruction
> >
> >
> > This access is part of KASAN check. But the original address kernel
> > tries to access is NULL, so it's not an issue with KASAN.
> >
> > The line is this:
> >
> > int security_inode_getattr(const struct path *path)
> > {
> >     if (unlikely(IS_PRIVATE(d_backing_inode(path->dentry))))
> >         return 0;
> >
> > So it's either path is NULL, or something in d_backing_inode
> > dereferences NULL path->dentry.
> >
> > The reproducer does involve overlayfs:
> >
> > mkdir(&(0x7f0000000240)='./file1\x00', 0x0)
> > mkdir(&(0x7f0000000300)='./bus\x00', 0x0)
> > r0 = creat(&(0x7f00000000c0)='./bus/file1\x00', 0x0)
> > mkdir(&(0x7f0000000080)='./file0\x00', 0x0)
> > mount$overlay(0x400002, &(0x7f0000000000)='./bus\x00',
> > &(0x7f0000000100)='overlay\x00', 0x0,
> > &(0x7f00000003c0)=ANY=[@ANYBLOB='upperdir=./file1,lowerdir=./bus,workdir=./file0,metacopy=on'])
> > link(&(0x7f0000000200)='./bus/file1\x00', &(0x7f00000002c0)='./bus/file0\x00')
> > write$RDMA_USER_CM_CMD_RESOLVE_ADDR(r0, 0x0, 0x0)
> > acct(&(0x7f0000000040)='./bus/file0\x00')
> >
> > Though, it may be overlayfs-related, or it may be a generic bug that
> > requires a tricky reproducer and the only reproducer syzbot come up
> > with happened to involve overlayfs.
> > But there are 4 reproducers on syzbot dashboard and all of them
> > involve overlayfs and they are somewhat different. So my bet would be
> > on overlayfs.
>
> Seems there's no C reproducer, though.   Can this be reproduced
> without KASAN obfuscating the oops?

I guess so.
If you are interest in what exact field is NULL, I think there is
enough info in the asm already:

> > >    2: 49 8d 5e 08          lea    0x8(%r14),%rbx
> > >    6: 48 89 d8              mov    %rbx,%rax
> > >    9: 48 c1 e8 03          shr    $0x3,%rax
> > >    d: 42 80 3c 38 00        cmpb   $0x0,(%rax,%r15,1)
> > >   12: 74 08                je     0x1c
> > >   14: 48 89 df              mov    %rbx,%rdi
> > >   17: e8 bc b4 5b fe        callq  0xfffffffffe5bb4d8
> > >   1c: 48 8b 1b              mov    (%rbx),%rbx
> > >   1f: 48 83 c3 68          add    $0x68,%rbx
> > >   23: 48 89 d8              mov    %rbx,%rax
> > >   26: 48 c1 e8 03          shr    $0x3,%rax
> > >   2a:* 42 80 3c 38 00        cmpb   $0x0,(%rax,%r15,1) <-- trapping instruction

The access via the NULL pointer happens with offset 0x68:

> > >   1f: 48 83 c3 68          add    $0x68,%rbx

So we just need to find what's here accesses with offset 0x68:

> >     if (unlikely(IS_PRIVATE(d_backing_inode(path->dentry))))

And that pointer itself was loaded from something at offset 0x8 previously:

> > >    2: 49 8d 5e 08          lea    0x8(%r14),%rbx

Re: general protection fault in security_inode_getattr

[syzbot]

syzbot has bisected this issue to:

commit 35697c12d7ffd31a56d3c9604066a166b75d0169
Author: Yonghong Song <yhs@fb.com>
Date:   Thu Jan 16 17:40:04 2020 +0000

    selftests/bpf: Fix test_progs send_signal flakiness with nmi mode

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=13032139900000
start commit:   d012a719 Linux 5.9-rc2
git tree:       upstream
final oops:     https://syzkaller.appspot.com/x/report.txt?x=10832139900000
console output: https://syzkaller.appspot.com/x/log.txt?x=17032139900000
kernel config:  https://syzkaller.appspot.com/x/.config?x=891ca5711a9f1650
dashboard link: https://syzkaller.appspot.com/bug?extid=f07cc9be8d1d226947ed
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=104a650e900000

Reported-by: syzbot+f07cc9be8d1d226947ed@syzkaller.appspotmail.com
Fixes: 35697c12d7ff ("selftests/bpf: Fix test_progs send_signal flakiness with nmi mode")

For information about bisection process see: https://goo.gl/tpsmEJ#bisection

Re: general protection fault in security_inode_getattr

[Yonghong Song]

On 8/24/20 5:32 PM, syzbot wrote:
> syzbot has bisected this issue to:
> 
> commit 35697c12d7ffd31a56d3c9604066a166b75d0169
> Author: Yonghong Song <yhs@fb.com>
> Date:   Thu Jan 16 17:40:04 2020 +0000
> 
>      selftests/bpf: Fix test_progs send_signal flakiness with nmi mode

The above patch changed file:
     tools/testing/selftests/bpf/prog_tests/send_signal.c
It is unlikely it caused the issue.

> 
> bisection log:  https://urldefense.proofpoint.com/v2/url?u=https-3A__syzkaller.appspot.com_x_bisect.txt-3Fx-3D13032139900000&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=DA8e1B5r073vIqRrFz7MRA&m=854z77F3pbTpgGUCFUwM1OSEUj4NbiNIZsaad0Xg4qc&s=Le6D_jfzkec28_qNhbUwMesaUeBGaKEG6RLN3ZCzE1s&e=
> start commit:   d012a719 Linux 5.9-rc2
> git tree:       upstream
> final oops:     https://urldefense.proofpoint.com/v2/url?u=https-3A__syzkaller.appspot.com_x_report.txt-3Fx-3D10832139900000&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=DA8e1B5r073vIqRrFz7MRA&m=854z77F3pbTpgGUCFUwM1OSEUj4NbiNIZsaad0Xg4qc&s=VbLXb22TgxAtiPQTEq0t5r0WgNDiFwstWKnme0tWBLE&e=
> console output: https://urldefense.proofpoint.com/v2/url?u=https-3A__syzkaller.appspot.com_x_log.txt-3Fx-3D17032139900000&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=DA8e1B5r073vIqRrFz7MRA&m=854z77F3pbTpgGUCFUwM1OSEUj4NbiNIZsaad0Xg4qc&s=yu72HnqjHzOTtJ5dyD7q0QW9sOwEO6pPHjeYTTutKdc&e=
> kernel config:  https://urldefense.proofpoint.com/v2/url?u=https-3A__syzkaller.appspot.com_x_.config-3Fx-3D891ca5711a9f1650&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=DA8e1B5r073vIqRrFz7MRA&m=854z77F3pbTpgGUCFUwM1OSEUj4NbiNIZsaad0Xg4qc&s=6cylIRBZjHQmgkJQoofuLN2XSifb-13qrrj58PQpBYs&e=
> dashboard link: https://urldefense.proofpoint.com/v2/url?u=https-3A__syzkaller.appspot.com_bug-3Fextid-3Df07cc9be8d1d226947ed&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=DA8e1B5r073vIqRrFz7MRA&m=854z77F3pbTpgGUCFUwM1OSEUj4NbiNIZsaad0Xg4qc&s=siCrm2aO-fzR3Nym_zaPQQnmxMlJo0bRj87zgm7o5mY&e=
> syz repro:      https://urldefense.proofpoint.com/v2/url?u=https-3A__syzkaller.appspot.com_x_repro.syz-3Fx-3D104a650e900000&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=DA8e1B5r073vIqRrFz7MRA&m=854z77F3pbTpgGUCFUwM1OSEUj4NbiNIZsaad0Xg4qc&s=yNEvyRe2bO4AKgq2UuJc32katp4k4UGKwMUDEBlhM7E&e=
> 
> Reported-by: syzbot+f07cc9be8d1d226947ed@syzkaller.appspotmail.com
> Fixes: 35697c12d7ff ("selftests/bpf: Fix test_progs send_signal flakiness with nmi mode")
> 
> For information about bisection process see: https://urldefense.proofpoint.com/v2/url?u=https-3A__goo.gl_tpsmEJ-23bisection&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=DA8e1B5r073vIqRrFz7MRA&m=854z77F3pbTpgGUCFUwM1OSEUj4NbiNIZsaad0Xg4qc&s=K4KdZK8rBgxDv4M9uwEndkCB4mCatTH-opwefN-0b-M&e=
> 

Re: [syzbot] general protection fault in security_inode_getattr

[syzbot]

syzbot has found a reproducer for the following issue on:

HEAD commit:    55be6084c8e0 Merge tag 'timers-core-2022-10-05' of git://g..
git tree:       upstream
console+strace: https://syzkaller.appspot.com/x/log.txt?x=147637c6880000
kernel config:  https://syzkaller.appspot.com/x/.config?x=df75278aabf0681a
dashboard link: https://syzkaller.appspot.com/bug?extid=f07cc9be8d1d226947ed
compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=1585a0c2880000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1480a464880000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/6c791937c012/disk-55be6084.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/cb21a2879b4c/vmlinux-55be6084.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/2d56267ed26f/mount_1.gz

The issue was bisected to:

commit 35697c12d7ffd31a56d3c9604066a166b75d0169
Author: Yonghong Song <yhs@fb.com>
Date:   Thu Jan 16 17:40:04 2020 +0000

    selftests/bpf: Fix test_progs send_signal flakiness with nmi mode

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=13032139900000
final oops:     https://syzkaller.appspot.com/x/report.txt?x=10832139900000
console output: https://syzkaller.appspot.com/x/log.txt?x=17032139900000

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+f07cc9be8d1d226947ed@syzkaller.appspotmail.com
Fixes: 35697c12d7ff ("selftests/bpf: Fix test_progs send_signal flakiness with nmi mode")

general protection fault, probably for non-canonical address 0xdffffc000000000d: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f]
CPU: 0 PID: 3761 Comm: syz-executor352 Not tainted 6.0.0-syzkaller-09589-g55be6084c8e0 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
RIP: 0010:d_backing_inode include/linux/dcache.h:542 [inline]
RIP: 0010:security_inode_getattr+0x46/0x140 security/security.c:1345
Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 04 01 00 00 48 b8 00 00 00 00 00 fc ff df 49 8b 5d 08 48 8d 7b 68 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 d7 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b
RSP: 0018:ffffc9000400f578 EFLAGS: 00010212
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 000000000000000d RSI: ffffffff83bd72fe RDI: 0000000000000068
RBP: ffffc9000400f750 R08: 0000000000000005 R09: 0000000000000000
R10: 0000000000000000 R11: 000000000008c07d R12: ffff8880763dca48
R13: ffffc9000400f750 R14: 00000000000007ff R15: 0000000000000000
FS:  00007f246f27e700(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f246f27e718 CR3: 00000000717a9000 CR4: 0000000000350ef0
Call Trace:
 <TASK>
 vfs_getattr+0x22/0x60 fs/stat.c:158
 ovl_copy_up_one+0x12c/0x2870 fs/overlayfs/copy_up.c:965
 ovl_copy_up_flags+0x150/0x1d0 fs/overlayfs/copy_up.c:1047
 ovl_maybe_copy_up+0x140/0x190 fs/overlayfs/copy_up.c:1079
 ovl_open+0xf1/0x2d0 fs/overlayfs/file.c:152
 do_dentry_open+0x6cc/0x13f0 fs/open.c:882
 do_open fs/namei.c:3557 [inline]
 path_openat+0x1c92/0x28f0 fs/namei.c:3691
 do_filp_open+0x1b6/0x400 fs/namei.c:3718
 do_sys_openat2+0x16d/0x4c0 fs/open.c:1310
 do_sys_open fs/open.c:1326 [inline]
 __do_sys_open fs/open.c:1334 [inline]
 __se_sys_open fs/open.c:1330 [inline]
 __x64_sys_open+0x119/0x1c0 fs/open.c:1330
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f246f2f2b49
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f246f27e2f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000002
RAX: ffffffffffffffda RBX: 00007f246f3774b0 RCX: 00007f246f2f2b49
RDX: 0000000000000000 RSI: 0000000000000300 RDI: 0000000020000140
RBP: 00007f246f3442ac R08: 00007f246f27e700 R09: 0000000000000000
R10: 00007f246f27e700 R11: 0000000000000246 R12: 0031656c69662f2e
R13: 79706f636174656d R14: 0079616c7265766f R15: 00007f246f3774b8
 </TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:d_backing_inode include/linux/dcache.h:542 [inline]
RIP: 0010:security_inode_getattr+0x46/0x140 security/security.c:1345
Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 04 01 00 00 48 b8 00 00 00 00 00 fc ff df 49 8b 5d 08 48 8d 7b 68 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 d7 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b
RSP: 0018:ffffc9000400f578 EFLAGS: 00010212
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 000000000000000d RSI: ffffffff83bd72fe RDI: 0000000000000068
RBP: ffffc9000400f750 R08: 0000000000000005 R09: 0000000000000000
R10: 0000000000000000 R11: 000000000008c07d R12: ffff8880763dca48
R13: ffffc9000400f750 R14: 00000000000007ff R15: 0000000000000000
FS:  00007f246f27e700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005643c9471000 CR3: 00000000717a9000 CR4: 0000000000350ee0
----------------
Code disassembly (best guess):
   0:	48 89 fa             	mov    %rdi,%rdx
   3:	48 c1 ea 03          	shr    $0x3,%rdx
   7:	80 3c 02 00          	cmpb   $0x0,(%rdx,%rax,1)
   b:	0f 85 04 01 00 00    	jne    0x115
  11:	48 b8 00 00 00 00 00 	movabs $0xdffffc0000000000,%rax
  18:	fc ff df
  1b:	49 8b 5d 08          	mov    0x8(%r13),%rbx
  1f:	48 8d 7b 68          	lea    0x68(%rbx),%rdi
  23:	48 89 fa             	mov    %rdi,%rdx
  26:	48 c1 ea 03          	shr    $0x3,%rdx
* 2a:	80 3c 02 00          	cmpb   $0x0,(%rdx,%rax,1) <-- trapping instruction
  2e:	0f 85 d7 00 00 00    	jne    0x10b
  34:	48 b8 00 00 00 00 00 	movabs $0xdffffc0000000000,%rax
  3b:	fc ff df
  3e:	48                   	rex.W
  3f:	8b                   	.byte 0x8b

Re: [syzbot] general protection fault in security_inode_getattr

[Paul Moore]

On Sat, Oct 15, 2022 at 1:24 PM syzbot
<syzbot+f07cc9be8d1d226947ed@syzkaller.appspotmail.com> wrote:
>
> syzbot has found a reproducer for the following issue on:
>
> HEAD commit:    55be6084c8e0 Merge tag 'timers-core-2022-10-05' of git://g..
> git tree:       upstream
> console+strace: https://syzkaller.appspot.com/x/log.txt?x=147637c6880000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=df75278aabf0681a
> dashboard link: https://syzkaller.appspot.com/bug?extid=f07cc9be8d1d226947ed
> compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=1585a0c2880000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1480a464880000
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/6c791937c012/disk-55be6084.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/cb21a2879b4c/vmlinux-55be6084.xz
> mounted in repro: https://storage.googleapis.com/syzbot-assets/2d56267ed26f/mount_1.gz
>
> The issue was bisected to:
>
> commit 35697c12d7ffd31a56d3c9604066a166b75d0169
> Author: Yonghong Song <yhs@fb.com>
> Date:   Thu Jan 16 17:40:04 2020 +0000
>
>     selftests/bpf: Fix test_progs send_signal flakiness with nmi mode
>
> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=13032139900000
> final oops:     https://syzkaller.appspot.com/x/report.txt?x=10832139900000
> console output: https://syzkaller.appspot.com/x/log.txt?x=17032139900000
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+f07cc9be8d1d226947ed@syzkaller.appspotmail.com
> Fixes: 35697c12d7ff ("selftests/bpf: Fix test_progs send_signal flakiness with nmi mode")
>
> general protection fault, probably for non-canonical address 0xdffffc000000000d: 0000 [#1] PREEMPT SMP KASAN
> KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f]
> CPU: 0 PID: 3761 Comm: syz-executor352 Not tainted 6.0.0-syzkaller-09589-g55be6084c8e0 #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
> RIP: 0010:d_backing_inode include/linux/dcache.h:542 [inline]
> RIP: 0010:security_inode_getattr+0x46/0x140 security/security.c:1345
> Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 04 01 00 00 48 b8 00 00 00 00 00 fc ff df 49 8b 5d 08 48 8d 7b 68 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 d7 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b
> RSP: 0018:ffffc9000400f578 EFLAGS: 00010212
> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
> RDX: 000000000000000d RSI: ffffffff83bd72fe RDI: 0000000000000068
> RBP: ffffc9000400f750 R08: 0000000000000005 R09: 0000000000000000
> R10: 0000000000000000 R11: 000000000008c07d R12: ffff8880763dca48
> R13: ffffc9000400f750 R14: 00000000000007ff R15: 0000000000000000
> FS:  00007f246f27e700(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007f246f27e718 CR3: 00000000717a9000 CR4: 0000000000350ef0
> Call Trace:
>  <TASK>
>  vfs_getattr+0x22/0x60 fs/stat.c:158
>  ovl_copy_up_one+0x12c/0x2870 fs/overlayfs/copy_up.c:965
>  ovl_copy_up_flags+0x150/0x1d0 fs/overlayfs/copy_up.c:1047
>  ovl_maybe_copy_up+0x140/0x190 fs/overlayfs/copy_up.c:1079
>  ovl_open+0xf1/0x2d0 fs/overlayfs/file.c:152
>  do_dentry_open+0x6cc/0x13f0 fs/open.c:882
>  do_open fs/namei.c:3557 [inline]
>  path_openat+0x1c92/0x28f0 fs/namei.c:3691
>  do_filp_open+0x1b6/0x400 fs/namei.c:3718
>  do_sys_openat2+0x16d/0x4c0 fs/open.c:1310
>  do_sys_open fs/open.c:1326 [inline]
>  __do_sys_open fs/open.c:1334 [inline]
>  __se_sys_open fs/open.c:1330 [inline]
>  __x64_sys_open+0x119/0x1c0 fs/open.c:1330
>  do_syscall_x64 arch/x86/entry/common.c:50 [inline]
>  do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
>  entry_SYSCALL_64_after_hwframe+0x63/0xcd
> RIP: 0033:0x7f246f2f2b49
> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007f246f27e2f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000002
> RAX: ffffffffffffffda RBX: 00007f246f3774b0 RCX: 00007f246f2f2b49
> RDX: 0000000000000000 RSI: 0000000000000300 RDI: 0000000020000140
> RBP: 00007f246f3442ac R08: 00007f246f27e700 R09: 0000000000000000
> R10: 00007f246f27e700 R11: 0000000000000246 R12: 0031656c69662f2e
> R13: 79706f636174656d R14: 0079616c7265766f R15: 00007f246f3774b8
>  </TASK>
> Modules linked in:
> ---[ end trace 0000000000000000 ]---

It doesn't look like this is a problem with
security_inode_getattr()/d_backing_inode() as it appears that the
passed path struct pointer has a bogus/NULL path->dentry pointer and
to the best of my knowledge it would appear that vfs_getattr() (the
caller) requires a valid path->dentry value.

Looking quickly at the code, I wonder if there is something wonky
going on in the overlayfs code, specifically ovl_copy_up_flags() and
ovl_copy_up_one() as they have to play a number of tricks to handle
the transparent overlays and copy up operations.  I'm not an overlayfs
expert, but that seems like a good place to start digging further into
this.

-- 
paul-moore.com

Re: [syzbot] general protection fault in security_inode_getattr

[Tetsuo Handa]

On 2022/10/16 23:52, Paul Moore wrote:
> It doesn't look like this is a problem with
> security_inode_getattr()/d_backing_inode() as it appears that the
> passed path struct pointer has a bogus/NULL path->dentry pointer and
> to the best of my knowledge it would appear that vfs_getattr() (the
> caller) requires a valid path->dentry value.
> 
> Looking quickly at the code, I wonder if there is something wonky
> going on in the overlayfs code, specifically ovl_copy_up_flags() and
> ovl_copy_up_one() as they have to play a number of tricks to handle
> the transparent overlays and copy up operations.  I'm not an overlayfs
> expert, but that seems like a good place to start digging further into
> this.

Right. This is a bug in overlayfs code. Probably due to some race condition,
ovl_copy_up_flags() is calling ovl_copy_up_one() with "next" dentry with
"struct ovl_entry"->numlower == 0. As a result, ovl_path_lower() from
ovl_copy_up_one() fills ctx.lowerpath with NULLs, and vfs_getattr() gets
surprised by ctx.lowerpath.dentry == NULL.

If we can't avoid selecting a dentry with "struct ovl_entry"->numlower == 0 using
some lock, I guess that we would need to use a workaround suggested by Hillf Danton
at https://groups.google.com/g/syzkaller-bugs/c/xDcxFKSppfE/m/b38Tv7LoAAAJ .

Re: [syzbot] general protection fault in security_inode_getattr

[Yonghong Song]

On 10/15/22 10:24 AM, syzbot wrote:
> syzbot has found a reproducer for the following issue on:
> 
> HEAD commit:    55be6084c8e0 Merge tag 'timers-core-2022-10-05' of git://g..
> git tree:       upstream
> console+strace: https://syzkaller.appspot.com/x/log.txt?x=147637c6880000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=df75278aabf0681a
> dashboard link: https://syzkaller.appspot.com/bug?extid=f07cc9be8d1d226947ed
> compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=1585a0c2880000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1480a464880000
> 
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/6c791937c012/disk-55be6084.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/cb21a2879b4c/vmlinux-55be6084.xz
> mounted in repro: https://storage.googleapis.com/syzbot-assets/2d56267ed26f/mount_1.gz
> 
> The issue was bisected to:
> 
> commit 35697c12d7ffd31a56d3c9604066a166b75d0169
> Author: Yonghong Song <yhs@fb.com>
> Date:   Thu Jan 16 17:40:04 2020 +0000
> 
>      selftests/bpf: Fix test_progs send_signal flakiness with nmi mode

It cannot be this patch as it tried to modify a bpf selftest and it
should not impact the kernel.

> 
> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=13032139900000
> final oops:     https://syzkaller.appspot.com/x/report.txt?x=10832139900000
> console output: https://syzkaller.appspot.com/x/log.txt?x=17032139900000
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+f07cc9be8d1d226947ed@syzkaller.appspotmail.com
> Fixes: 35697c12d7ff ("selftests/bpf: Fix test_progs send_signal flakiness with nmi mode")
> 
> general protection fault, probably for non-canonical address 0xdffffc000000000d: 0000 [#1] PREEMPT SMP KASAN
> KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f]
> CPU: 0 PID: 3761 Comm: syz-executor352 Not tainted 6.0.0-syzkaller-09589-g55be6084c8e0 #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
> RIP: 0010:d_backing_inode include/linux/dcache.h:542 [inline]
> RIP: 0010:security_inode_getattr+0x46/0x140 security/security.c:1345
> Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 04 01 00 00 48 b8 00 00 00 00 00 fc ff df 49 8b 5d 08 48 8d 7b 68 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 d7 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b
> RSP: 0018:ffffc9000400f578 EFLAGS: 00010212
> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
> RDX: 000000000000000d RSI: ffffffff83bd72fe RDI: 0000000000000068
> RBP: ffffc9000400f750 R08: 0000000000000005 R09: 0000000000000000
> R10: 0000000000000000 R11: 000000000008c07d R12: ffff8880763dca48
> R13: ffffc9000400f750 R14: 00000000000007ff R15: 0000000000000000
> FS:  00007f246f27e700(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007f246f27e718 CR3: 00000000717a9000 CR4: 0000000000350ef0
> Call Trace:
>   <TASK>
>   vfs_getattr+0x22/0x60 fs/stat.c:158
>   ovl_copy_up_one+0x12c/0x2870 fs/overlayfs/copy_up.c:965
>   ovl_copy_up_flags+0x150/0x1d0 fs/overlayfs/copy_up.c:1047
>   ovl_maybe_copy_up+0x140/0x190 fs/overlayfs/copy_up.c:1079
>   ovl_open+0xf1/0x2d0 fs/overlayfs/file.c:152
>   do_dentry_open+0x6cc/0x13f0 fs/open.c:882
>   do_open fs/namei.c:3557 [inline]
>   path_openat+0x1c92/0x28f0 fs/namei.c:3691
>   do_filp_open+0x1b6/0x400 fs/namei.c:3718
>   do_sys_openat2+0x16d/0x4c0 fs/open.c:1310
>   do_sys_open fs/open.c:1326 [inline]
>   __do_sys_open fs/open.c:1334 [inline]
>   __se_sys_open fs/open.c:1330 [inline]
>   __x64_sys_open+0x119/0x1c0 fs/open.c:1330
>   do_syscall_x64 arch/x86/entry/common.c:50 [inline]
>   do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
>   entry_SYSCALL_64_after_hwframe+0x63/0xcd
> RIP: 0033:0x7f246f2f2b49
> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007f246f27e2f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000002
> RAX: ffffffffffffffda RBX: 00007f246f3774b0 RCX: 00007f246f2f2b49
> RDX: 0000000000000000 RSI: 0000000000000300 RDI: 0000000020000140
> RBP: 00007f246f3442ac R08: 00007f246f27e700 R09: 0000000000000000
> R10: 00007f246f27e700 R11: 0000000000000246 R12: 0031656c69662f2e
> R13: 79706f636174656d R14: 0079616c7265766f R15: 00007f246f3774b8
>   </TASK>
> Modules linked in:
> ---[ end trace 0000000000000000 ]---
> RIP: 0010:d_backing_inode include/linux/dcache.h:542 [inline]
> RIP: 0010:security_inode_getattr+0x46/0x140 security/security.c:1345
> Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 04 01 00 00 48 b8 00 00 00 00 00 fc ff df 49 8b 5d 08 48 8d 7b 68 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 d7 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b
> RSP: 0018:ffffc9000400f578 EFLAGS: 00010212
> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
> RDX: 000000000000000d RSI: ffffffff83bd72fe RDI: 0000000000000068
> RBP: ffffc9000400f750 R08: 0000000000000005 R09: 0000000000000000
> R10: 0000000000000000 R11: 000000000008c07d R12: ffff8880763dca48
> R13: ffffc9000400f750 R14: 00000000000007ff R15: 0000000000000000
> FS:  00007f246f27e700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00005643c9471000 CR3: 00000000717a9000 CR4: 0000000000350ee0
> ----------------
> Code disassembly (best guess):
>     0:	48 89 fa             	mov    %rdi,%rdx
>     3:	48 c1 ea 03          	shr    $0x3,%rdx
>     7:	80 3c 02 00          	cmpb   $0x0,(%rdx,%rax,1)
>     b:	0f 85 04 01 00 00    	jne    0x115
>    11:	48 b8 00 00 00 00 00 	movabs $0xdffffc0000000000,%rax
>    18:	fc ff df
>    1b:	49 8b 5d 08          	mov    0x8(%r13),%rbx
>    1f:	48 8d 7b 68          	lea    0x68(%rbx),%rdi
>    23:	48 89 fa             	mov    %rdi,%rdx
>    26:	48 c1 ea 03          	shr    $0x3,%rdx
> * 2a:	80 3c 02 00          	cmpb   $0x0,(%rdx,%rax,1) <-- trapping instruction
>    2e:	0f 85 d7 00 00 00    	jne    0x10b
>    34:	48 b8 00 00 00 00 00 	movabs $0xdffffc0000000000,%rax
>    3b:	fc ff df
>    3e:	48                   	rex.W
>    3f:	8b                   	.byte 0x8b
> 

Re: general protection fault in security_inode_getattr

[Andrey Kalachev]

On Wed, Jul 29, 2020 at 01:23:18PM -0700, syzbot wrote:
>Hello,
>
>syzbot found the following issue on:
>
>HEAD commit:    92ed3019 Linux 5.8-rc7
>git tree:       upstream
>console output: https://syzkaller.appspot.com/x/log.txt?x=140003ac900000
>kernel config:  https://syzkaller.appspot.com/x/.config?x=84f076779e989e69
>dashboard link: https://syzkaller.appspot.com/bug?extid=f07cc9be8d1d226947ed
>compiler:       gcc (GCC) 10.1.0-syz 20200507
>
>Unfortunately, I don't have any reproducer for this issue yet.
>
>IMPORTANT: if you fix the issue, please add the following tag to the commit:
>Reported-by: syzbot+f07cc9be8d1d226947ed@syzkaller.appspotmail.com
>
>general protection fault, probably for non-canonical address 0xdffffc000000000c: 0000 [#1] PREEMPT SMP KASAN
>KASAN: null-ptr-deref in range [0x0000000000000060-0x0000000000000067]
>CPU: 0 PID: 9214 Comm: syz-executor.3 Not tainted 5.8.0-rc7-syzkaller #0
>Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
>RIP: 0010:d_backing_inode include/linux/dcache.h:549 [inline]
>RIP: 0010:security_inode_getattr+0x46/0x140 security/security.c:1276
>Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 04 01 00 00 48 b8 00 00 00 00 00 fc ff df 49 8b 5d 08 48 8d 7b 60 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 d7 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b
>RSP: 0018:ffffc9000d41f638 EFLAGS: 00010206
>RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc9000f539000
>RDX: 000000000000000c RSI: ffffffff8354f8ee RDI: 0000000000000060
>RBP: ffffc9000d41f810 R08: 0000000000000001 R09: ffff88804edc2dc8
>R10: 0000000000000000 R11: 00000000000ebc58 R12: ffff888089f10170
>R13: ffffc9000d41f810 R14: 00000000000007ff R15: 0000000000000000
>FS:  00007f3599717700(0000) GS:ffff8880ae600000(0000) knlGS:0000000000000000
>CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>CR2: 0000001b2c12c000 CR3: 0000000099919000 CR4: 00000000001406f0
>DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
>Call Trace:
> vfs_getattr+0x22/0x60 fs/stat.c:121
> ovl_copy_up_one+0x13b/0x1870 fs/overlayfs/copy_up.c:850
> ovl_copy_up_flags+0x14b/0x1d0 fs/overlayfs/copy_up.c:931
> ovl_maybe_copy_up+0x140/0x190 fs/overlayfs/copy_up.c:963
> ovl_open+0xba/0x270 fs/overlayfs/file.c:147
> do_dentry_open+0x501/0x1290 fs/open.c:828
> do_open fs/namei.c:3243 [inline]
> path_openat+0x1bb9/0x2750 fs/namei.c:3360
> do_filp_open+0x17e/0x3c0 fs/namei.c:3387
> file_open_name+0x290/0x400 fs/open.c:1124
> acct_on+0x78/0x770 kernel/acct.c:207
> __do_sys_acct kernel/acct.c:286 [inline]
> __se_sys_acct kernel/acct.c:273 [inline]
> __x64_sys_acct+0xab/0x1f0 kernel/acct.c:273
> do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:384
> entry_SYSCALL_64_after_hwframe+0x44/0xa9
>RIP: 0033:0x45c369
>Code: 8d b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 5b b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00
>RSP: 002b:00007f3599716c78 EFLAGS: 00000246 ORIG_RAX: 00000000000000a3
>RAX: ffffffffffffffda RBX: 0000000000000700 RCX: 000000000045c369
>RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000020000440
>RBP: 000000000078bf30 R08: 0000000000000000 R09: 0000000000000000
>R10: 0000000000000000 R11: 0000000000000246 R12: 000000000078bf0c
>R13: 00007ffda41ffbef R14: 00007f35997179c0 R15: 000000000078bf0c
>Modules linked in:
>---[ end trace d1398a63985d3915 ]---
>RIP: 0010:d_backing_inode include/linux/dcache.h:549 [inline]
>RIP: 0010:security_inode_getattr+0x46/0x140 security/security.c:1276
>Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 04 01 00 00 48 b8 00 00 00 00 00 fc ff df 49 8b 5d 08 48 8d 7b 60 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 d7 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b
>RSP: 0018:ffffc9000d41f638 EFLAGS: 00010206
>RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc9000f539000
>RDX: 000000000000000c RSI: ffffffff8354f8ee RDI: 0000000000000060
>RBP: ffffc9000d41f810 R08: 0000000000000001 R09: ffff88804edc2dc8
>R10: 0000000000000000 R11: 00000000000ebc58 R12: ffff888089f10170
>R13: ffffc9000d41f810 R14: 00000000000007ff R15: 0000000000000000
>FS:  00007f3599717700(0000) GS:ffff8880ae600000(0000) knlGS:0000000000000000
>CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>CR2: 0000000020000440 CR3: 0000000099919000 CR4: 00000000001406f0
>DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
>
>
>---
>This report is generated by a bot. It may contain errors.
>See https://goo.gl/tpsmEJ for more information about syzbot.
>syzbot engineers can be reached at syzkaller@googlegroups.com.
>
>syzbot will keep track of this issue. See:
>https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

Hello,

I've found that the bug fixed by commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0af950f57fefabab628f1963af881e6b9bfe7f38
merged with mainline here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=be3c213150dc4370ef211a78d78457ff166eba4e

Kernel release 6.5 include the fixed code.

Hence, the stable kernels up to 6.5 still affected.
I've got early version (4.19.139) from syzbot report, here is the first time when been reported.
Maybe previous versions are also affected, I haven't checked it.

I've only deal with stable 5.10 and 6.1, here I can confirm the issue.

The tracing results showed that GPF caused by the dentry shared between two processes.
Suppose we have a regular file `A` onto lower overlayfs layer, metacopy=on.
P1 execute link syscall ( `A` link to `B`), P2 do open `B`.

   P1          P2

   sys_link
               sys_open
                 ovl_lookup B -- lookup non existent `B`, alloc `B` dentry
                   ovl_alloc_entry -- non existent file, zero filled ovl_entry

     ovl_link -- link A to B, use same dentry `B`, dentry associated with
     `A`, lower layer file now.

   sys_link -- return to userspace, zero filled ovl_entry `B` untouched

                     ovl_open B, reuse the same dentry `B`
                       ovl_copy_up_one
                         ovl_path_lower
                           ovl_numlower(oe) -- return 0, numlower in zero filled ovl_entry `oe`
                         ovl_path_lower -- return zero filled `struct path`
                         vfs_getattr(struct path, ..)
                           security_inode_getattr(struct path, ...)
                             d_backing_inode(path->dentry) -- NULL dereference, GPF

Stable kernel v6.1 can be easy fixed by 4 mainline commits transfer:

0af950f57fef ovl: move ovl_entry into ovl_inode
163db0da3515 ovl: factor out ovl_free_entry() and ovl_stack_*() helpers
5522c9c7cbd2 ovl: use ovl_numlower() and ovl_lowerstack() accessors
a6ff2bc0be17 ovl: use OVL_E() and OVL_E_FLAGS() accessors

Just commit 5522c9c7cbd2 has conflict caused by
4609e1f18e19c ("fs: port ->permission() to pass mnt_idmap").
It is enough to change mnt_idmap() call to mnt_user_ns(),
in the rejected hunk.

--
Andrey Kalachev
Software Engineer,
Swemel

Re: general protection fault in security_inode_getattr

[Amir Goldstein]

On Mon, Apr 1, 2024 at 8:43 PM Andrey Kalachev <kalachev@swemel.ru> wrote:
>
> On Wed, Jul 29, 2020 at 01:23:18PM -0700, syzbot wrote:
> >Hello,
> >
> >syzbot found the following issue on:
> >
> >HEAD commit:    92ed3019 Linux 5.8-rc7
> >git tree:       upstream
> >console output: https://syzkaller.appspot.com/x/log.txt?x=140003ac900000
> >kernel config:  https://syzkaller.appspot.com/x/.config?x=84f076779e989e69
> >dashboard link: https://syzkaller.appspot.com/bug?extid=f07cc9be8d1d226947ed
> >compiler:       gcc (GCC) 10.1.0-syz 20200507
> >
> >Unfortunately, I don't have any reproducer for this issue yet.
> >
> >IMPORTANT: if you fix the issue, please add the following tag to the commit:
> >Reported-by: syzbot+f07cc9be8d1d226947ed@syzkaller.appspotmail.com
> >
> >general protection fault, probably for non-canonical address 0xdffffc000000000c: 0000 [#1] PREEMPT SMP KASAN
> >KASAN: null-ptr-deref in range [0x0000000000000060-0x0000000000000067]
> >CPU: 0 PID: 9214 Comm: syz-executor.3 Not tainted 5.8.0-rc7-syzkaller #0
> >Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> >RIP: 0010:d_backing_inode include/linux/dcache.h:549 [inline]
> >RIP: 0010:security_inode_getattr+0x46/0x140 security/security.c:1276
> >Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 04 01 00 00 48 b8 00 00 00 00 00 fc ff df 49 8b 5d 08 48 8d 7b 60 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 d7 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b
> >RSP: 0018:ffffc9000d41f638 EFLAGS: 00010206
> >RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc9000f539000
> >RDX: 000000000000000c RSI: ffffffff8354f8ee RDI: 0000000000000060
> >RBP: ffffc9000d41f810 R08: 0000000000000001 R09: ffff88804edc2dc8
> >R10: 0000000000000000 R11: 00000000000ebc58 R12: ffff888089f10170
> >R13: ffffc9000d41f810 R14: 00000000000007ff R15: 0000000000000000
> >FS:  00007f3599717700(0000) GS:ffff8880ae600000(0000) knlGS:0000000000000000
> >CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> >CR2: 0000001b2c12c000 CR3: 0000000099919000 CR4: 00000000001406f0
> >DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> >DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> >Call Trace:
> > vfs_getattr+0x22/0x60 fs/stat.c:121
> > ovl_copy_up_one+0x13b/0x1870 fs/overlayfs/copy_up.c:850
> > ovl_copy_up_flags+0x14b/0x1d0 fs/overlayfs/copy_up.c:931
> > ovl_maybe_copy_up+0x140/0x190 fs/overlayfs/copy_up.c:963
> > ovl_open+0xba/0x270 fs/overlayfs/file.c:147
> > do_dentry_open+0x501/0x1290 fs/open.c:828
> > do_open fs/namei.c:3243 [inline]
> > path_openat+0x1bb9/0x2750 fs/namei.c:3360
> > do_filp_open+0x17e/0x3c0 fs/namei.c:3387
> > file_open_name+0x290/0x400 fs/open.c:1124
> > acct_on+0x78/0x770 kernel/acct.c:207
> > __do_sys_acct kernel/acct.c:286 [inline]
> > __se_sys_acct kernel/acct.c:273 [inline]
> > __x64_sys_acct+0xab/0x1f0 kernel/acct.c:273
> > do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:384
> > entry_SYSCALL_64_after_hwframe+0x44/0xa9
> >RIP: 0033:0x45c369
> >Code: 8d b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 5b b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> >RSP: 002b:00007f3599716c78 EFLAGS: 00000246 ORIG_RAX: 00000000000000a3
> >RAX: ffffffffffffffda RBX: 0000000000000700 RCX: 000000000045c369
> >RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000020000440
> >RBP: 000000000078bf30 R08: 0000000000000000 R09: 0000000000000000
> >R10: 0000000000000000 R11: 0000000000000246 R12: 000000000078bf0c
> >R13: 00007ffda41ffbef R14: 00007f35997179c0 R15: 000000000078bf0c
> >Modules linked in:
> >---[ end trace d1398a63985d3915 ]---
> >RIP: 0010:d_backing_inode include/linux/dcache.h:549 [inline]
> >RIP: 0010:security_inode_getattr+0x46/0x140 security/security.c:1276
> >Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 04 01 00 00 48 b8 00 00 00 00 00 fc ff df 49 8b 5d 08 48 8d 7b 60 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 d7 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b
> >RSP: 0018:ffffc9000d41f638 EFLAGS: 00010206
> >RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc9000f539000
> >RDX: 000000000000000c RSI: ffffffff8354f8ee RDI: 0000000000000060
> >RBP: ffffc9000d41f810 R08: 0000000000000001 R09: ffff88804edc2dc8
> >R10: 0000000000000000 R11: 00000000000ebc58 R12: ffff888089f10170
> >R13: ffffc9000d41f810 R14: 00000000000007ff R15: 0000000000000000
> >FS:  00007f3599717700(0000) GS:ffff8880ae600000(0000) knlGS:0000000000000000
> >CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> >CR2: 0000000020000440 CR3: 0000000099919000 CR4: 00000000001406f0
> >DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> >DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> >
> >
> >---
> >This report is generated by a bot. It may contain errors.
> >See https://goo.gl/tpsmEJ for more information about syzbot.
> >syzbot engineers can be reached at syzkaller@googlegroups.com.
> >
> >syzbot will keep track of this issue. See:
> >https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
>
> Hello,
>
> I've found that the bug fixed by commit:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0af950f57fefabab628f1963af881e6b9bfe7f38
> merged with mainline here:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=be3c213150dc4370ef211a78d78457ff166eba4e
>
> Kernel release 6.5 include the fixed code.
>
> Hence, the stable kernels up to 6.5 still affected.
> I've got early version (4.19.139) from syzbot report, here is the first time when been reported.
> Maybe previous versions are also affected, I haven't checked it.
>
> I've only deal with stable 5.10 and 6.1, here I can confirm the issue.
>
> The tracing results showed that GPF caused by the dentry shared between two processes.
> Suppose we have a regular file `A` onto lower overlayfs layer, metacopy=on.
> P1 execute link syscall ( `A` link to `B`), P2 do open `B`.
>
>    P1          P2
>
>    sys_link
>                sys_open
>                  ovl_lookup B -- lookup non existent `B`, alloc `B` dentry
>                    ovl_alloc_entry -- non existent file, zero filled ovl_entry
>
>      ovl_link -- link A to B, use same dentry `B`, dentry associated with
>      `A`, lower layer file now.
>
>    sys_link -- return to userspace, zero filled ovl_entry `B` untouched
>
>                      ovl_open B, reuse the same dentry `B`
>                        ovl_copy_up_one
>                          ovl_path_lower
>                            ovl_numlower(oe) -- return 0, numlower in zero filled ovl_entry `oe`
>                          ovl_path_lower -- return zero filled `struct path`
>                          vfs_getattr(struct path, ..)
>                            security_inode_getattr(struct path, ...)
>                              d_backing_inode(path->dentry) -- NULL dereference, GPF
>
> Stable kernel v6.1 can be easy fixed by 4 mainline commits transfer:
>
> 0af950f57fef ovl: move ovl_entry into ovl_inode
> 163db0da3515 ovl: factor out ovl_free_entry() and ovl_stack_*() helpers
> 5522c9c7cbd2 ovl: use ovl_numlower() and ovl_lowerstack() accessors
> a6ff2bc0be17 ovl: use OVL_E() and OVL_E_FLAGS() accessors
>
> Just commit 5522c9c7cbd2 has conflict caused by
> 4609e1f18e19c ("fs: port ->permission() to pass mnt_idmap").
> It is enough to change mnt_idmap() call to mnt_user_ns(),
> in the rejected hunk.

Hi Andrey,

I don't have time to review this backport series, but in my memory,
these few commits were part of a much larger refactoring and
I am almost positive that there are fix commits that mention
Fixes: 0af950f57fef ("ovl: move ovl_entry into ovl_inode") in upstream kernel.

If you do want to backport overlayfs changes to stable kernels, you should
specify how you tested them and that should include at least running
the latest fstests overlayfs tests.

Thanks,
Amir.

Re: general protection fault in security_inode_getattr

[Andrey Kalachev]

[-- Attachment #1: Type: text/plain, Size: 8692 bytes --]

On Tue, Apr 02, 2024 at 07:01:57PM +0300, Amir Goldstein wrote:
>On Mon, Apr 1, 2024 at 8:43 PM Andrey Kalachev <kalachev@swemel.ru> wrote:
>>
>> On Wed, Jul 29, 2020 at 01:23:18PM -0700, syzbot wrote:
>> >Hello,
>> >
>> >syzbot found the following issue on:
>> >
>> >HEAD commit:    92ed3019 Linux 5.8-rc7
>> >git tree:       upstream
>> >console output: https://syzkaller.appspot.com/x/log.txt?x=140003ac900000
>> >kernel config:  https://syzkaller.appspot.com/x/.config?x=84f076779e989e69
>> >dashboard link: https://syzkaller.appspot.com/bug?extid=f07cc9be8d1d226947ed
>> >compiler:       gcc (GCC) 10.1.0-syz 20200507
>> >
>> >Unfortunately, I don't have any reproducer for this issue yet.
>> >
>> >IMPORTANT: if you fix the issue, please add the following tag to the commit:
>> >Reported-by: syzbot+f07cc9be8d1d226947ed@syzkaller.appspotmail.com
>> >
>> >general protection fault, probably for non-canonical address 0xdffffc000000000c: 0000 [#1] PREEMPT SMP KASAN
>> >KASAN: null-ptr-deref in range [0x0000000000000060-0x0000000000000067]
>> >CPU: 0 PID: 9214 Comm: syz-executor.3 Not tainted 5.8.0-rc7-syzkaller #0
>> >Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
>> >RIP: 0010:d_backing_inode include/linux/dcache.h:549 [inline]
>> >RIP: 0010:security_inode_getattr+0x46/0x140 security/security.c:1276
>> >Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 04 01 00 00 48 b8 00 00 00 00 00 fc ff df 49 8b 5d 08 48 8d 7b 60 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 d7 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b
>> >RSP: 0018:ffffc9000d41f638 EFLAGS: 00010206
>> >RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc9000f539000
>> >RDX: 000000000000000c RSI: ffffffff8354f8ee RDI: 0000000000000060
>> >RBP: ffffc9000d41f810 R08: 0000000000000001 R09: ffff88804edc2dc8
>> >R10: 0000000000000000 R11: 00000000000ebc58 R12: ffff888089f10170
>> >R13: ffffc9000d41f810 R14: 00000000000007ff R15: 0000000000000000
>> >FS:  00007f3599717700(0000) GS:ffff8880ae600000(0000) knlGS:0000000000000000
>> >CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> >CR2: 0000001b2c12c000 CR3: 0000000099919000 CR4: 00000000001406f0
>> >DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> >DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
>> >Call Trace:
>> > vfs_getattr+0x22/0x60 fs/stat.c:121
>> > ovl_copy_up_one+0x13b/0x1870 fs/overlayfs/copy_up.c:850
>> > ovl_copy_up_flags+0x14b/0x1d0 fs/overlayfs/copy_up.c:931
>> > ovl_maybe_copy_up+0x140/0x190 fs/overlayfs/copy_up.c:963
>> > ovl_open+0xba/0x270 fs/overlayfs/file.c:147
>> > do_dentry_open+0x501/0x1290 fs/open.c:828
>> > do_open fs/namei.c:3243 [inline]
>> > path_openat+0x1bb9/0x2750 fs/namei.c:3360
>> > do_filp_open+0x17e/0x3c0 fs/namei.c:3387
>> > file_open_name+0x290/0x400 fs/open.c:1124
>> > acct_on+0x78/0x770 kernel/acct.c:207
>> > __do_sys_acct kernel/acct.c:286 [inline]
>> > __se_sys_acct kernel/acct.c:273 [inline]
>> > __x64_sys_acct+0xab/0x1f0 kernel/acct.c:273
>> > do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:384
>> > entry_SYSCALL_64_after_hwframe+0x44/0xa9
>> >RIP: 0033:0x45c369
>> >Code: 8d b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 5b b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00
>> >RSP: 002b:00007f3599716c78 EFLAGS: 00000246 ORIG_RAX: 00000000000000a3
>> >RAX: ffffffffffffffda RBX: 0000000000000700 RCX: 000000000045c369
>> >RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000020000440
>> >RBP: 000000000078bf30 R08: 0000000000000000 R09: 0000000000000000
>> >R10: 0000000000000000 R11: 0000000000000246 R12: 000000000078bf0c
>> >R13: 00007ffda41ffbef R14: 00007f35997179c0 R15: 000000000078bf0c
>> >Modules linked in:
>> >---[ end trace d1398a63985d3915 ]---
>> >RIP: 0010:d_backing_inode include/linux/dcache.h:549 [inline]
>> >RIP: 0010:security_inode_getattr+0x46/0x140 security/security.c:1276
>> >Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 04 01 00 00 48 b8 00 00 00 00 00 fc ff df 49 8b 5d 08 48 8d 7b 60 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 d7 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b
>> >RSP: 0018:ffffc9000d41f638 EFLAGS: 00010206
>> >RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc9000f539000
>> >RDX: 000000000000000c RSI: ffffffff8354f8ee RDI: 0000000000000060
>> >RBP: ffffc9000d41f810 R08: 0000000000000001 R09: ffff88804edc2dc8
>> >R10: 0000000000000000 R11: 00000000000ebc58 R12: ffff888089f10170
>> >R13: ffffc9000d41f810 R14: 00000000000007ff R15: 0000000000000000
>> >FS:  00007f3599717700(0000) GS:ffff8880ae600000(0000) knlGS:0000000000000000
>> >CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> >CR2: 0000000020000440 CR3: 0000000099919000 CR4: 00000000001406f0
>> >DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> >DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
>> >
>> >
>> >---
>> >This report is generated by a bot. It may contain errors.
>> >See https://goo.gl/tpsmEJ for more information about syzbot.
>> >syzbot engineers can be reached at syzkaller@googlegroups.com.
>> >
>> >syzbot will keep track of this issue. See:
>> >https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
>>
>> Hello,
>>
>> I've found that the bug fixed by commit:
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0af950f57fefabab628f1963af881e6b9bfe7f38
>> merged with mainline here:
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=be3c213150dc4370ef211a78d78457ff166eba4e
>>
>> Kernel release 6.5 include the fixed code.
>>
>> Hence, the stable kernels up to 6.5 still affected.
>> I've got early version (4.19.139) from syzbot report, here is the first time when been reported.
>> Maybe previous versions are also affected, I haven't checked it.
>>
>> I've only deal with stable 5.10 and 6.1, here I can confirm the issue.
>>
>> The tracing results showed that GPF caused by the dentry shared between two processes.
>> Suppose we have a regular file `A` onto lower overlayfs layer, metacopy=on.
>> P1 execute link syscall ( `A` link to `B`), P2 do open `B`.
>>
>>    P1          P2
>>
>>    sys_link
>>                sys_open
>>                  ovl_lookup B -- lookup non existent `B`, alloc `B` dentry
>>                    ovl_alloc_entry -- non existent file, zero filled ovl_entry
>>
>>      ovl_link -- link A to B, use same dentry `B`, dentry associated with
>>      `A`, lower layer file now.
>>
>>    sys_link -- return to userspace, zero filled ovl_entry `B` untouched
>>
>>                      ovl_open B, reuse the same dentry `B`
>>                        ovl_copy_up_one
>>                          ovl_path_lower
>>                            ovl_numlower(oe) -- return 0, numlower in zero filled ovl_entry `oe`
>>                          ovl_path_lower -- return zero filled `struct path`
>>                          vfs_getattr(struct path, ..)
>>                            security_inode_getattr(struct path, ...)
>>                              d_backing_inode(path->dentry) -- NULL dereference, GPF
>>
>> Stable kernel v6.1 can be easy fixed by 4 mainline commits transfer:
>>
>> 0af950f57fef ovl: move ovl_entry into ovl_inode
>> 163db0da3515 ovl: factor out ovl_free_entry() and ovl_stack_*() helpers
>> 5522c9c7cbd2 ovl: use ovl_numlower() and ovl_lowerstack() accessors
>> a6ff2bc0be17 ovl: use OVL_E() and OVL_E_FLAGS() accessors
>>
>> Just commit 5522c9c7cbd2 has conflict caused by
>> 4609e1f18e19c ("fs: port ->permission() to pass mnt_idmap").
>> It is enough to change mnt_idmap() call to mnt_user_ns(),
>> in the rejected hunk.
>
>Hi Andrey,
>
>I don't have time to review this backport series, but in my memory,
>these few commits were part of a much larger refactoring and
>I am almost positive that there are fix commits that mention
>Fixes: 0af950f57fef ("ovl: move ovl_entry into ovl_inode") in upstream kernel.
>
>If you do want to backport overlayfs changes to stable kernels, you should
>specify how you tested them and that should include at least running
>the latest fstests overlayfs tests.
>
>Thanks,
>Amir.

Hi Amir,

I gave up the idea of making backports series of upstream patches, I just did what Hillf Danton suggested here:

https://groups.google.com/g/syzkaller-bugs/c/xDcxFKSppfE/m/b38Tv7LoAAAJ .

This looks like a more universal solution, suitable for previous kernel versions, especially since the likelihood of such an error occurring is quite low.

I did regression testing with xfstests-dev + unionmount-testsuite on version 5.10.208 and found no additional failures.

Please take a look at the attached patch.

Thanks,
Andrey. 

[-- Attachment #2: 0001-ovl-fix-general-protection-fault-in-security_inode_g.patch --]
[-- Type: text/x-diff, Size: 2897 bytes --]

From: Andrey Kalachev <kalachev@swemel.ru>
Date: Fri, 19 Apr 2024 20:55:10 +0300
Subject: [PATCH] ovl: fix general protection fault in security_inode_getattr

general protection fault caused by dentry shared between two processes.
Suppose we have a regular file `A` onto lower overlayfs layer, metacopy=on.

Process P1 execute link syscall ( `A` link to `B`), P2 do open `B`.

P1         |  P2
-----------+--------------
sys_link   |
           | sys_open
           |   ovl_lookup B      (1)
           |     ovl_alloc_entry (2)
           |
  ovl_link |                     (3)
           |
           |
sys_link   |                     (4)
           |
           |     ovl_open B      (5)
           |       ovl_copy_up_one
           |         ovl_path_lower
           |           ovl_numlower(oe) (6)
           |         ovl_path_lower     (7)
           |           vfs_getattr(struct path, ..)
           |             security_inode_getattr(struct path, ...)
           |               d_backing_inode(path->dentry)

(1) P2 call ovl_lookup B, lookup non existent file `B`,
       new `B` dentry allocated.
(2) P2 call ovl_alloc_entry() in `non existent file` context,
       return zero filled ovl_entry.
(3) P1 make hardlink A -> B,
       now `B` dentry associated with lower layer file `A`.
(4) P1 return to userspace from `sys_link`,
       leave ovl_entry `B` unchanged (zeros).
(5) P2 continue open file behind dentry `B`.
(6) P2 ovl_numlower(oe) return 0,
       taken from zero filled ovl_entry `oe`
(7) P2 ovl_path_lower() return zero filled `struct path`, due numlower=0.
(8) P2 NULL dereference in d_backing_inode()

Since release v6.5 `ovl_entry` associated with inode and placed into
the `struct ovl_inode_params`.

Issue fixed at:
commit 0af950f57fef ("ovl: move ovl_entry into ovl_inode")

Solution, proposed by Hillf Danton, most common and suitable for
stable kernels before v6.5. The patch code is based on it.

Reported-by: syzbot+f07cc9be8d1d226947ed@syzkaller.appspotmail.com
Link: https://lore.kernel.org/lkml/0000000000008caae305ab9a5318@google.com
Link: https://syzkaller.appspot.com/bug?extid=f07cc9be8d1d226947ed
Signed-off-by: Andrey Kalachev <kalachev@swemel.ru>
---
 fs/overlayfs/copy_up.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/fs/overlayfs/copy_up.c b/fs/overlayfs/copy_up.c
index 65ac504595ba..b7352c43b673 100644
--- a/fs/overlayfs/copy_up.c
+++ b/fs/overlayfs/copy_up.c
@@ -879,6 +879,13 @@ static int ovl_copy_up_one(struct dentry *parent, struct dentry *dentry,
 		return -EROFS;
 
 	ovl_path_lower(dentry, &ctx.lowerpath);
+
+	if (unlikely(!ctx.lowerpath.dentry)) {
+		/* syzbot+f07cc9be8d1d226947ed@syzkaller.appspotmail.com */
+		pr_err("prevention GPF in security_inode_getattr()\n");
+		return -EIO;
+	}
+
 	err = vfs_getattr(&ctx.lowerpath, &ctx.stat,
 			  STATX_BASIC_STATS, AT_STATX_SYNC_AS_STAT);
 	if (err)
-- 
2.30.2