linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Qian Cai <cai@lca.pw>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	linux-fsdevel@vger.kernel.org,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: Null-ptr-deref due to "sanitized pathwalk machinery (v4)"
Date: Wed, 25 Mar 2020 09:21:59 -0400	[thread overview]
Message-ID: <B1AE49C8-A33E-4991-88D5-803DE044C560@lca.pw> (raw)
In-Reply-To: <20200325040359.GK23230@ZenIV.linux.org.uk>



> On Mar 25, 2020, at 12:03 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> 
> On Tue, Mar 24, 2020 at 11:24:01PM -0400, Qian Cai wrote:
> 
>>> On Mar 24, 2020, at 10:13 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>>> 
>>> On Tue, Mar 24, 2020 at 09:49:48PM -0400, Qian Cai wrote:
>>> 
>>>> It does not catch anything at all with the patch,
>>> 
>>> You mean, oops happens, but neither WARN_ON() is triggered?
>>> Lovely...  Just to make sure: could you slap the same couple
>>> of lines just before
>>>               if (unlikely(!d_can_lookup(nd->path.dentry))) {
>>> in link_path_walk(), just to check if I have misread the trace
>>> you've got?
>>> 
>>> Does that (+ other two inserts) end up with
>>> 	1) some of these WARN_ON() triggered when oops happens or
>>> 	2) oops is happening, but neither WARN_ON() triggers or
>>> 	3) oops not happening / becoming harder to hit?
>> 
>> Only the one just before
>> if (unlikely(!d_can_lookup(nd->path.dentry))) {
>> In link_path_walk() will trigger.
> 
>> [  245.767202][ T5020] pathname = /var/run/nscd/socket
> 
> Lovely.  So
> 	* we really do get NULL nd->path.dentry there; I've not misread the
> trace.
> 	* on the entry into link_path_walk() nd->path.dentry is non-NULL.
> 	* *ALL* components should've been LAST_NORM ones
> 	* not a single symlink in sight, unless the setup is rather unusual
> 	* possibly not even a single mountpoint along the way (depending
> upon the userland used)
> 
> And in the same loop we have
>                if (likely(type == LAST_NORM)) {
>                        struct dentry *parent = nd->path.dentry;
>                        nd->flags &= ~LOOKUP_JUMPED;
>                        if (unlikely(parent->d_flags & DCACHE_OP_HASH)) {
>                                struct qstr this = { { .hash_len = hash_len }, .name = name };
>                                err = parent->d_op->d_hash(parent, &this);
>                                if (err < 0)
>                                        return err;
>                                hash_len = this.hash_len;
>                                name = this.name;
>                        }
>                }
> upstream of that thing.  So NULL nd->path.dentry *there* would've oopsed.
> IOW, what we are hitting is walk_component() with non-NULL nd->path.dentry
> when we enter it, NULL being returned and nd->path.dentry becoming NULL
> by the time we return from walk_component().
> 
> Could you post the results of
> 	stat / /var /var/run /var/run/nscd /var/run/nscd/socket

The file is gone after a successful boot,

#  stat / /var /var/run /var/run/nscd /var/run/nscd/socket
  File: /
  Size: 244       	Blocks: 0          IO Block: 65536  directory
Device: fe00h/65024d	Inode: 128         Links: 17
Access: (0555/dr-xr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2020-03-24 14:21:27.112559236 -0400
Modify: 2020-03-24 14:21:25.840486593 -0400
Change: 2020-03-24 14:21:25.840486593 -0400
 Birth: -
  File: /var
  Size: 4096      	Blocks: 8          IO Block: 65536  directory
Device: fe00h/65024d	Inode: 133         Links: 21
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2018-08-12 05:57:57.000000000 -0400
Modify: 2020-03-23 21:29:31.087264900 -0400
Change: 2020-03-23 21:29:31.087264900 -0400
 Birth: -
  File: /var/run -> ../run
  Size: 6         	Blocks: 0          IO Block: 65536  symbolic link
Device: fe00h/65024d	Inode: 143         Links: 1
Access: (0777/lrwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2020-03-24 17:34:11.865030724 -0400
Modify: 2020-03-23 17:16:40.573974805 -0400
Change: 2020-03-23 17:16:40.573974805 -0400
 Birth: -
stat: cannot stat '/var/run/nscd': No such file or directory
stat: cannot stat '/var/run/nscd/socket': No such file or directory

> after the boot with working kernel?  Also, is that "hit on every boot" or
> stochastic?  If it's the latter, I'd like to see the output of the same
> thing on a successful boot of the same kernel, if possible...

It does not hit every time, so I used a cron job,

@reboot sleep 180; systemctl reboot

It has always hit it within a hour so far.


      parent reply	other threads:[~2020-03-25 13:22 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-24 21:06 Null-ptr-deref due to "sanitized pathwalk machinery (v4)" Qian Cai
2020-03-24 21:46 ` Al Viro
2020-03-25  1:49   ` Qian Cai
2020-03-25  2:13     ` Al Viro
2020-03-25  3:24       ` Qian Cai
2020-03-25  4:03         ` Al Viro
2020-03-25  5:58           ` Al Viro
2020-03-25 14:02             ` Al Viro
2020-03-25 14:05               ` Al Viro
2020-03-25 19:43             ` Qian Cai
2020-03-25 21:07               ` Al Viro
2020-03-25 13:21           ` Qian Cai [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=B1AE49C8-A33E-4991-88D5-803DE044C560@lca.pw \
    --to=cai@lca.pw \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).