lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 5 Jul 2023 16:39:10 +0300
From:   Amir Goldstein <amir73il@...il.com>
To:     Christian Brauner <brauner@...nel.org>
Cc:     syzbot <syzbot+a67fc5321ffb4b311c98@...kaller.appspotmail.com>,
        Jeff Layton <jlayton@...nel.org>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-unionfs@...r.kernel.org, miklos@...redi.hu,
        syzkaller-bugs@...glegroups.com, Mimi Zohar <zohar@...ux.ibm.com>
Subject: Re: [syzbot] [overlayfs?] general protection fault in d_path

On Wed, Jul 5, 2023 at 4:06 PM Christian Brauner <brauner@...nel.org> 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@...kaller.appspotmail.com
> >
> > 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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ