* Re: general protection fault in security_inode_getattr
[not found] ` <000000000000a726a405ada4b6cf@google.com>
@ 2020-08-24 21:00 ` Ondrej Mosnacek
2020-10-30 13:02 ` Miklos Szeredi
0 siblings, 1 reply; 11+ messages in thread
From: Ondrej Mosnacek @ 2020-08-24 21:00 UTC (permalink / raw)
To: syzbot
Cc: andriin, Alexei Starovoitov, bpf, Daniel Borkmann, James Morris,
john.fastabend, kafai, KP Singh, Linux kernel mailing list,
Linux Security Module list, network dev, Serge E. Hallyn,
songliubraving, syzkaller-bugs, yhs, linux-fsdevel,
Miklos Szeredi, linux-unionfs
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: general protection fault in security_inode_getattr
[not found] <0000000000008caae305ab9a5318@google.com>
[not found] ` <000000000000a726a405ada4b6cf@google.com>
@ 2020-08-25 0:32 ` syzbot
2020-08-25 0:48 ` Yonghong Song
2022-10-15 17:24 ` [syzbot] " syzbot
2 siblings, 1 reply; 11+ messages in thread
From: syzbot @ 2020-08-25 0:32 UTC (permalink / raw)
To: andriin, ast, bpf, daniel, jmorris, john.fastabend, kafai,
kpsingh, linux-fsdevel, linux-kernel, linux-security-module,
linux-unionfs, miklos, netdev, omosnace, serge, songliubraving,
syzkaller-bugs, yhs
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: general protection fault in security_inode_getattr
2020-08-25 0:32 ` syzbot
@ 2020-08-25 0:48 ` Yonghong Song
0 siblings, 0 replies; 11+ messages in thread
From: Yonghong Song @ 2020-08-25 0:48 UTC (permalink / raw)
To: syzbot, andriin, ast, bpf, daniel, jmorris, john.fastabend,
kafai, kpsingh, linux-fsdevel, linux-kernel,
linux-security-module, linux-unionfs, miklos, netdev, omosnace,
serge, songliubraving, syzkaller-bugs
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=
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: general protection fault in security_inode_getattr
2020-08-24 21:00 ` general protection fault in security_inode_getattr Ondrej Mosnacek
@ 2020-10-30 13:02 ` Miklos Szeredi
2020-10-30 18:42 ` Dmitry Vyukov
0 siblings, 1 reply; 11+ messages in thread
From: Miklos Szeredi @ 2020-10-30 13:02 UTC (permalink / raw)
To: Ondrej Mosnacek
Cc: syzbot, andriin, Alexei Starovoitov, bpf, Daniel Borkmann,
James Morris, john.fastabend, kafai, KP Singh,
Linux kernel mailing list, Linux Security Module list,
network dev, Serge E. Hallyn, Song Liu, syzkaller-bugs, yhs,
linux-fsdevel, overlayfs
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: general protection fault in security_inode_getattr
2020-10-30 13:02 ` Miklos Szeredi
@ 2020-10-30 18:42 ` Dmitry Vyukov
2020-10-30 19:21 ` Miklos Szeredi
0 siblings, 1 reply; 11+ messages in thread
From: Dmitry Vyukov @ 2020-10-30 18:42 UTC (permalink / raw)
To: Miklos Szeredi
Cc: Ondrej Mosnacek, syzbot, Andrii Nakryiko, Alexei Starovoitov,
bpf, Daniel Borkmann, James Morris, John Fastabend,
Martin KaFai Lau, KP Singh, Linux kernel mailing list,
Linux Security Module list, network dev, Serge E. Hallyn,
Song Liu, syzkaller-bugs, Yonghong Song, linux-fsdevel,
overlayfs
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: general protection fault in security_inode_getattr
2020-10-30 18:42 ` Dmitry Vyukov
@ 2020-10-30 19:21 ` Miklos Szeredi
2020-10-30 19:56 ` Dmitry Vyukov
0 siblings, 1 reply; 11+ messages in thread
From: Miklos Szeredi @ 2020-10-30 19:21 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Ondrej Mosnacek, syzbot, Andrii Nakryiko, Alexei Starovoitov,
bpf, Daniel Borkmann, James Morris, John Fastabend,
Martin KaFai Lau, KP Singh, Linux kernel mailing list,
Linux Security Module list, network dev, Serge E. Hallyn,
Song Liu, syzkaller-bugs, Yonghong Song, linux-fsdevel,
overlayfs
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: general protection fault in security_inode_getattr
2020-10-30 19:21 ` Miklos Szeredi
@ 2020-10-30 19:56 ` Dmitry Vyukov
0 siblings, 0 replies; 11+ messages in thread
From: Dmitry Vyukov @ 2020-10-30 19:56 UTC (permalink / raw)
To: Miklos Szeredi
Cc: Ondrej Mosnacek, syzbot, Andrii Nakryiko, Alexei Starovoitov,
bpf, Daniel Borkmann, James Morris, John Fastabend,
Martin KaFai Lau, KP Singh, Linux kernel mailing list,
Linux Security Module list, network dev, Serge E. Hallyn,
Song Liu, syzkaller-bugs, Yonghong Song, linux-fsdevel,
overlayfs
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [syzbot] general protection fault in security_inode_getattr
[not found] <0000000000008caae305ab9a5318@google.com>
[not found] ` <000000000000a726a405ada4b6cf@google.com>
2020-08-25 0:32 ` syzbot
@ 2022-10-15 17:24 ` syzbot
2022-10-16 14:52 ` Paul Moore
2022-10-17 5:38 ` Yonghong Song
2 siblings, 2 replies; 11+ messages in thread
From: syzbot @ 2022-10-15 17:24 UTC (permalink / raw)
To: andriin, ast, bpf, daniel, dvyukov, hdanton, jmorris,
john.fastabend, kafai, kpsingh, linux-fsdevel, linux-kernel,
linux-security-module, linux-unionfs, miklos, netdev, omosnace,
paul, serge, songliubraving, syzkaller-bugs, tonymarislogistics,
yhs
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [syzbot] general protection fault in security_inode_getattr
2022-10-15 17:24 ` [syzbot] " syzbot
@ 2022-10-16 14:52 ` Paul Moore
2022-10-17 14:29 ` Tetsuo Handa
2022-10-17 5:38 ` Yonghong Song
1 sibling, 1 reply; 11+ messages in thread
From: Paul Moore @ 2022-10-16 14:52 UTC (permalink / raw)
To: syzbot
Cc: andriin, ast, bpf, daniel, dvyukov, hdanton, jmorris,
john.fastabend, kafai, kpsingh, linux-fsdevel, linux-kernel,
linux-security-module, linux-unionfs, miklos, netdev, omosnace,
serge, songliubraving, syzkaller-bugs, tonymarislogistics, yhs
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [syzbot] general protection fault in security_inode_getattr
2022-10-15 17:24 ` [syzbot] " syzbot
2022-10-16 14:52 ` Paul Moore
@ 2022-10-17 5:38 ` Yonghong Song
1 sibling, 0 replies; 11+ messages in thread
From: Yonghong Song @ 2022-10-17 5:38 UTC (permalink / raw)
To: syzbot, andriin, ast, bpf, daniel, dvyukov, hdanton, jmorris,
john.fastabend, kafai, kpsingh, linux-fsdevel, linux-kernel,
linux-security-module, linux-unionfs, miklos, netdev, omosnace,
paul, serge, songliubraving, syzkaller-bugs, tonymarislogistics,
yhs
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
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [syzbot] general protection fault in security_inode_getattr
2022-10-16 14:52 ` Paul Moore
@ 2022-10-17 14:29 ` Tetsuo Handa
0 siblings, 0 replies; 11+ messages in thread
From: Tetsuo Handa @ 2022-10-17 14:29 UTC (permalink / raw)
To: Paul Moore, miklos, linux-unionfs
Cc: dvyukov, hdanton, linux-fsdevel, syzkaller-bugs, syzbot, yhs, omosnace
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 .
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2022-10-17 14:30 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <0000000000008caae305ab9a5318@google.com>
[not found] ` <000000000000a726a405ada4b6cf@google.com>
2020-08-24 21:00 ` general protection fault in security_inode_getattr Ondrej Mosnacek
2020-10-30 13:02 ` Miklos Szeredi
2020-10-30 18:42 ` Dmitry Vyukov
2020-10-30 19:21 ` Miklos Szeredi
2020-10-30 19:56 ` Dmitry Vyukov
2020-08-25 0:32 ` syzbot
2020-08-25 0:48 ` Yonghong Song
2022-10-15 17:24 ` [syzbot] " syzbot
2022-10-16 14:52 ` Paul Moore
2022-10-17 14:29 ` Tetsuo Handa
2022-10-17 5:38 ` Yonghong Song
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).