Re: general protection fault in security_inode_getattr

From: Andrey Kalachev
Date: Mon Apr 01 2024 - 13:43:23 EST

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

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@xxxxxxxxxxxxxxxx.

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