* general protection fault in security_inode_getattr @ 2020-07-29 20:23 syzbot 2020-08-24 19:37 ` syzbot ` (3 more replies) 0 siblings, 4 replies; 16+ messages in thread From: syzbot @ 2020-07-29 20:23 UTC (permalink / raw) To: andriin, ast, bpf, daniel, jmorris, john.fastabend, kafai, kpsingh, linux-kernel, linux-security-module, netdev, serge, songliubraving, syzkaller-bugs, yhs 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: general protection fault in security_inode_getattr 2020-07-29 20:23 general protection fault in security_inode_getattr syzbot @ 2020-08-24 19:37 ` syzbot 2020-08-24 21:00 ` Ondrej Mosnacek 2020-08-25 0:32 ` syzbot ` (2 subsequent siblings) 3 siblings, 1 reply; 16+ messages in thread From: syzbot @ 2020-08-24 19:37 UTC (permalink / raw) To: andriin, ast, bpf, daniel, jmorris, john.fastabend, kafai, kpsingh, linux-kernel, linux-security-module, netdev, serge, songliubraving, syzkaller-bugs, yhs syzbot has found a reproducer for the following issue on: 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: general protection fault in security_inode_getattr 2020-08-24 19:37 ` syzbot @ 2020-08-24 21:00 ` Ondrej Mosnacek 2020-10-30 13:02 ` Miklos Szeredi 0 siblings, 1 reply; 16+ 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] 16+ messages in thread
* Re: general protection fault in security_inode_getattr 2020-08-24 21:00 ` Ondrej Mosnacek @ 2020-10-30 13:02 ` Miklos Szeredi 2020-10-30 18:42 ` Dmitry Vyukov 0 siblings, 1 reply; 16+ 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] 16+ 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; 16+ 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] 16+ 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; 16+ 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] 16+ 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; 16+ 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] 16+ messages in thread
* Re: general protection fault in security_inode_getattr 2020-07-29 20:23 general protection fault in security_inode_getattr syzbot 2020-08-24 19:37 ` syzbot @ 2020-08-25 0:32 ` syzbot 2020-08-25 0:48 ` Yonghong Song 2022-10-15 17:24 ` [syzbot] " syzbot 2024-04-01 17:36 ` Andrey Kalachev 3 siblings, 1 reply; 16+ 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] 16+ 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; 16+ 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] 16+ messages in thread
* Re: [syzbot] general protection fault in security_inode_getattr 2020-07-29 20:23 general protection fault in security_inode_getattr syzbot 2020-08-24 19:37 ` syzbot 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 2024-04-01 17:36 ` Andrey Kalachev 3 siblings, 2 replies; 16+ 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] 16+ 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; 16+ 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] 16+ 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; 16+ 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] 16+ 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; 16+ 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] 16+ messages in thread
* Re: general protection fault in security_inode_getattr 2020-07-29 20:23 general protection fault in security_inode_getattr syzbot ` (2 preceding siblings ...) 2022-10-15 17:24 ` [syzbot] " syzbot @ 2024-04-01 17:36 ` Andrey Kalachev 2024-04-02 16:01 ` Amir Goldstein 3 siblings, 1 reply; 16+ messages in thread From: Andrey Kalachev @ 2024-04-01 17:36 UTC (permalink / raw) To: syzbot Cc: andriin, ast, bpf, daniel, jmorris, john.fastabend, kafai, kpsingh, linux-kernel, linux-security-module, netdev, serge, songliubraving, syzkaller-bugs, yhs, miklos, linux-unionfs, lvc-project 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: general protection fault in security_inode_getattr 2024-04-01 17:36 ` Andrey Kalachev @ 2024-04-02 16:01 ` Amir Goldstein 2024-04-19 20:01 ` Andrey Kalachev 0 siblings, 1 reply; 16+ messages in thread From: Amir Goldstein @ 2024-04-02 16:01 UTC (permalink / raw) To: Andrey Kalachev Cc: syzbot, andriin, ast, bpf, daniel, jmorris, john.fastabend, kafai, kpsingh, linux-kernel, linux-security-module, netdev, serge, songliubraving, syzkaller-bugs, yhs, miklos, linux-unionfs, lvc-project 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: general protection fault in security_inode_getattr 2024-04-02 16:01 ` Amir Goldstein @ 2024-04-19 20:01 ` Andrey Kalachev 0 siblings, 0 replies; 16+ messages in thread From: Andrey Kalachev @ 2024-04-19 20:01 UTC (permalink / raw) To: Amir Goldstein Cc: syzbot, andriin, ast, bpf, daniel, jmorris, john.fastabend, kafai, kpsingh, linux-kernel, linux-security-module, netdev, serge, songliubraving, syzkaller-bugs, yhs, miklos, linux-unionfs, lvc-project [-- 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 ^ permalink raw reply related [flat|nested] 16+ messages in thread
end of thread, other threads:[~2024-04-19 20:10 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-07-29 20:23 general protection fault in security_inode_getattr syzbot 2020-08-24 19:37 ` syzbot 2020-08-24 21:00 ` 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 2024-04-01 17:36 ` Andrey Kalachev 2024-04-02 16:01 ` Amir Goldstein 2024-04-19 20:01 ` Andrey Kalachev
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).