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.
prev 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).