linux-kernel - RE: [PATCH 13/14] d_path: prepend_path() is unlikely to return non-zero

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:   Mon, 28 Jun 2021 03:28:19 +0000
From:   Justin He <Justin.He@....com>
To:     Al Viro <viro@...iv.linux.org.uk>
CC:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Petr Mladek <pmladek@...e.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Sergey Senozhatsky <senozhatsky@...omium.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Rasmus Villemoes <linux@...musvillemoes.dk>,
        Jonathan Corbet <corbet@....net>,
        Heiko Carstens <hca@...ux.ibm.com>,
        Vasily Gorbik <gor@...ux.ibm.com>,
        Christian Borntraeger <borntraeger@...ibm.com>,
        "Eric W . Biederman" <ebiederm@...ssion.com>,
        "Darrick J. Wong" <darrick.wong@...cle.com>,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        Ira Weiny <ira.weiny@...el.com>,
        Eric Biggers <ebiggers@...gle.com>,
        "Ahmed S. Darwish" <a.darwish@...utronix.de>,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-s390 <linux-s390@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: RE: [PATCH 13/14] d_path: prepend_path() is unlikely to return
 non-zero

Hi Al

> -----Original Message-----
> From: Al Viro <viro@....linux.org.uk> On Behalf Of Al Viro
> Sent: Saturday, June 26, 2021 1:59 AM
> To: Justin He <Justin.He@....com>
> Cc: Linus Torvalds <torvalds@...ux-foundation.org>; Petr Mladek
> <pmladek@...e.com>; Steven Rostedt <rostedt@...dmis.org>; Sergey
> Senozhatsky <senozhatsky@...omium.org>; Andy Shevchenko
> <andriy.shevchenko@...ux.intel.com>; Rasmus Villemoes
> <linux@...musvillemoes.dk>; Jonathan Corbet <corbet@....net>; Heiko
> Carstens <hca@...ux.ibm.com>; Vasily Gorbik <gor@...ux.ibm.com>; Christian
> Borntraeger <borntraeger@...ibm.com>; Eric W . Biederman
> <ebiederm@...ssion.com>; Darrick J. Wong <darrick.wong@...cle.com>; Peter
> Zijlstra (Intel) <peterz@...radead.org>; Ira Weiny <ira.weiny@...el.com>;
> Eric Biggers <ebiggers@...gle.com>; Ahmed S. Darwish
> <a.darwish@...utronix.de>; open list:DOCUMENTATION <linux-
> doc@...r.kernel.org>; Linux Kernel Mailing List <linux-
> kernel@...r.kernel.org>; linux-s390 <linux-s390@...r.kernel.org>; linux-
> fsdevel <linux-fsdevel@...r.kernel.org>
> Subject: Re: [PATCH 13/14] d_path: prepend_path() is unlikely to return
> non-zero
>
> On Fri, Jun 25, 2021 at 08:00:49AM +0000, Justin He wrote:
> > --- a/fs/d_path.c
> > +++ b/fs/d_path.c
> > @@ -210,6 +210,7 @@ static int prepend_path(const struct path *path,
> >         b = *p;
> >         read_seqbegin_or_lock(&rename_lock, &seq);
> >         error = __prepend_path(path->dentry, real_mount(path->mnt), root,
> &b);
> > +       printk("prepend=%d",error);
> >         if (!(seq & 1))
> >                 rcu_read_unlock();
> >         if (need_seqretry(&rename_lock, seq)) {
> >
> > Then the result seems a little different:
> > root@...os-ampere-02:~# dmesg |grep prepend=1 |wc -l
> > 7417
> > root@...os-ampere-02:~# dmesg |grep prepend=0 |wc -l
> > 772
> >
> > The kernel is 5.13.0-rc2+ + this series + my '%pD' series
> >
> > Any thoughts?
>
> On which loads?  1 here is "mount/dentry pair is in somebody
> else's namespace or outside of the subtree we are chrooted
> into".  IOW, what's calling d_path() on your setup?

No special loads, merely collecting the results after kernel boots up.

To narrow down, I tested your branch [1] *without* my '%pD' series:
[1] https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git/log/?h=work.d_path

The result is the same after kernel boots up.

The call trace are as follows:
The prepend_path returns 1:
  Call trace:
   prepend_path+0x144/0x340
   d_absolute_path+0x6c/0xb8
   aa_path_name+0x1c0/0x3d8
   profile_transition+0x90/0x908
   apparmor_bprm_creds_for_exec+0x914/0xaf0
   security_bprm_creds_for_exec+0x34/0x50
   bprm_execve+0x178/0x668
   do_execveat_common.isra.47+0x1b4/0x1c8
   __arm64_sys_execve+0x44/0x58
   invoke_syscall+0x54/0x110
   el0_svc_common.constprop.2+0x5c/0xe0
   do_el0_svc+0x34/0xa0
   el0_svc+0x20/0x30
   el0_sync_handler+0x88/0xb0
   el0_sync+0x148/0x180

The prepend_path returns 0:
  Call trace:
   prepend_path+0x144/0x340
   d_path+0x110/0x158
   proc_pid_readlink+0xbc/0x1b8
   vfs_readlink+0x14c/0x170
   do_readlinkat+0x134/0x168
   __arm64_sys_readlinkat+0x28/0x38
   invoke_syscall+0x54/0x110
   el0_svc_common.constprop.2+0x5c/0xe0
   do_el0_svc+0x34/0xa0
   el0_svc+0x20/0x30
   el0_sync_handler+0x88/0xb0
   el0_sync+0x148/0x180


IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.