On Wed, Jul 5, 2023 at 4:06 PM Christian Brauner <brauner@xxxxxxxxxx> wrote: > > On Wed, Jul 05, 2023 at 05:00:45AM -0700, syzbot wrote: > > Hello, > > > > syzbot found the following issue on: > > > > HEAD commit: d528014517f2 Revert ".gitignore: ignore *.cover and *.mbx" > > git tree: upstream > > console output: https://syzkaller.appspot.com/x/log.txt?x=14fad002a80000 > > kernel config: https://syzkaller.appspot.com/x/.config?x=1085b4238c9eb6ba > > dashboard link: https://syzkaller.appspot.com/bug?extid=a67fc5321ffb4b311c98 > > compiler: Debian clang version 15.0.7, GNU ld (GNU Binutils for Debian) 2.35.2 > > > > Unfortunately, I don't have any reproducer for this issue yet. > > > > Downloadable assets: > > disk image: https://storage.googleapis.com/syzbot-assets/fef94e788067/disk-d5280145.raw.xz > > vmlinux: https://storage.googleapis.com/syzbot-assets/576412ea518b/vmlinux-d5280145.xz > > kernel image: https://storage.googleapis.com/syzbot-assets/685a0e4be06b/bzImage-d5280145.xz > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > Reported-by: syzbot+a67fc5321ffb4b311c98@xxxxxxxxxxxxxxxxxxxxxxxxx > > > > general protection fault, probably for non-canonical address 0xdffffc000000000a: 0000 [#1] PREEMPT SMP KASAN > > KASAN: null-ptr-deref in range [0x0000000000000050-0x0000000000000057] > > CPU: 1 PID: 10127 Comm: syz-executor.3 Not tainted 6.4.0-syzkaller-11478-gd528014517f2 #0 > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023 > > RIP: 0010:__lock_acquire+0x10d/0x7f70 kernel/locking/lockdep.c:5012 > > Code: 85 75 18 00 00 83 3d 15 c8 2c 0d 00 48 89 9c 24 10 01 00 00 0f 84 f8 0f 00 00 83 3d 5c de b3 0b 00 74 34 48 89 d0 48 c1 e8 03 <42> 80 3c 00 00 74 1a 48 89 d7 e8 b4 51 79 00 48 8b 94 24 80 00 00 > > RSP: 0018:ffffc900169be9e0 EFLAGS: 00010006 > > RAX: 000000000000000a RBX: 1ffff92002d37d60 RCX: 0000000000000002 > > RDX: 0000000000000050 RSI: 0000000000000000 RDI: 0000000000000050 > > RBP: ffffc900169beca8 R08: dffffc0000000000 R09: 0000000000000001 > > R10: dffffc0000000000 R11: fffffbfff1d2fe76 R12: 0000000000000000 > > R13: 0000000000000001 R14: 0000000000000002 R15: ffff88802091d940 > > FS: 0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 > > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > CR2: 00007fa22a3fe000 CR3: 000000004b5e1000 CR4: 00000000003506e0 > > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > > Call Trace: > > <TASK> > > lock_acquire+0x1e3/0x520 kernel/locking/lockdep.c:5761 > > seqcount_lockdep_reader_access+0x139/0x220 include/linux/seqlock.h:102 > > get_fs_root_rcu fs/d_path.c:244 [inline] > > d_path+0x2f0/0x6e0 fs/d_path.c:286 > > audit_log_d_path+0xd3/0x310 kernel/audit.c:2139 > > dump_common_audit_data security/lsm_audit.c:224 [inline] > > common_lsm_audit+0x7cf/0x1a90 security/lsm_audit.c:458 > > smack_log+0x421/0x540 security/smack/smack_access.c:383 > > smk_tskacc+0x2ff/0x360 security/smack/smack_access.c:253 > > smack_inode_getattr+0x203/0x270 security/smack/smack_lsm.c:1202 > > security_inode_getattr+0xd3/0x120 security/security.c:2114 > > vfs_getattr+0x25/0x70 fs/stat.c:167 > > ovl_getattr+0x1b1/0xf70 fs/overlayfs/inode.c:174 > > ima_check_last_writer security/integrity/ima/ima_main.c:171 [inline] > > ima_file_free+0x26e/0x4b0 security/integrity/ima/ima_main.c:203 > > Ugh, I think the root of this might all be the call back into > vfs_getattr() that happens on overlayfs: > > __fput() > -> ima_file_free() > -> mutex_lock() > -> vfs_getattr_nosec() > -> i_op->getattr() == ovl_getattr() > -> vfs_getattr() > -> security_inode_getattr() > -> mutex_unlock() > > So either overlayfs needs to call vfs_getattr_nosec() when the request > comes from vfs_getattr_nosec() or this needs to use > backing_file_real_path() to operate on the real underlying path. > > Thoughts? The latter. IMA code cannot operate on a mixture of real inode (file_inode()) real dentry (file_dentry()) and ovl path, especially for reading stat.change_cookie which is not really well defined in ovl. At least those direct f_path references need to be fixed: security/integrity/ima/ima_main.c: vfs_getattr_nosec(&file->f_path, &stat, security/integrity/ima/ima_api.c: result = vfs_getattr_nosec(&file->f_path, &stat, STATX_CHANGE_COOKIE, security/integrity/ima/ima_crypto.c: f = dentry_open(&file->f_path, flags, file->f_cred); and then all the places that format full path for audit logs: security/integrity/ima/ima_main.c: *pathname = ima_d_path(&file->f_path, pathbuf, filename); Need to decide if it is prefered to log the full ovl path or the relative real path (relative to the private mount clone of the ovl layer). Thanks, Amir.
