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: [email protected]
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 [email protected].
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
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: [email protected]
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
On Mon, Aug 24, 2020 at 9:37 PM syzbot
<[email protected]> 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/[email protected]/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: [email protected]
>
> 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.
syzbot has bisected this issue to:
commit 35697c12d7ffd31a56d3c9604066a166b75d0169
Author: Yonghong Song <[email protected]>
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: [email protected]
Fixes: 35697c12d7ff ("selftests/bpf: Fix test_progs send_signal flakiness with nmi mode")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
On 8/24/20 5:32 PM, syzbot wrote:
> syzbot has bisected this issue to:
>
> commit 35697c12d7ffd31a56d3c9604066a166b75d0169
> Author: Yonghong Song <[email protected]>
> 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: [email protected]
> 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=
>
On Mon, Aug 24, 2020 at 11:00 PM Ondrej Mosnacek <[email protected]> wrote:
>
> On Mon, Aug 24, 2020 at 9:37 PM syzbot
> <[email protected]> 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
On Fri, Oct 30, 2020 at 2:02 PM Miklos Szeredi <[email protected]> wrote:
>
> On Mon, Aug 24, 2020 at 11:00 PM Ondrej Mosnacek <[email protected]> wrote:
> >
> > On Mon, Aug 24, 2020 at 9:37 PM syzbot
> > <[email protected]> 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.
On Fri, Oct 30, 2020 at 7:42 PM Dmitry Vyukov <[email protected]> wrote:
>
> On Fri, Oct 30, 2020 at 2:02 PM Miklos Szeredi <[email protected]> wrote:
> >
> > On Mon, Aug 24, 2020 at 11:00 PM Ondrej Mosnacek <[email protected]> wrote:
> > >
> > > On Mon, Aug 24, 2020 at 9:37 PM syzbot
> > > <[email protected]> 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
On Fri, Oct 30, 2020 at 8:21 PM Miklos Szeredi <[email protected]> wrote:
> > > On Mon, Aug 24, 2020 at 11:00 PM Ondrej Mosnacek <[email protected]> wrote:
> > > >
> > > > On Mon, Aug 24, 2020 at 9:37 PM syzbot
> > > > <[email protected]> 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
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 <[email protected]>
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: [email protected]
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
On Sat, Oct 15, 2022 at 1:24 PM syzbot
<[email protected]> 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 <[email protected]>
> 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: [email protected]
> 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
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 <[email protected]>
> 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: [email protected]
> 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
>
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 .
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: [email protected]
>
>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 [email protected].
>
>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
On Mon, Apr 1, 2024 at 8:43 PM Andrey Kalachev <[email protected]> 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: [email protected]
> >
> >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 [email protected].
> >
> >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.
On Tue, Apr 02, 2024 at 07:01:57PM +0300, Amir Goldstein wrote:
>On Mon, Apr 1, 2024 at 8:43 PM Andrey Kalachev <[email protected]> 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: [email protected]
>> >
>> >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 [email protected].
>> >
>> >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.