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]
Message-ID: <87h8mhgsh3.fsf@xmission.com>
Date:   Tue, 05 Jun 2018 10:31:36 -0500
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     "Hatayama\, Daisuke" <d.hatayama@...fujitsu.com>
Cc:     "'gregkh\@linuxfoundation.org'" <gregkh@...uxfoundation.org>,
        "'tj\@kernel.org'" <tj@...nel.org>,
        "Okajima\, Toshiyuki" <toshi.okajima@...fujitsu.com>,
        "linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
        "'ebiederm\@aristanetworks.com'" <ebiederm@...stanetworks.com>
Subject: Re: [CFT][PATCH] kernfs: Correct kernfs directory seeks.

"Hatayama, Daisuke" <d.hatayama@...fujitsu.com> writes:

>> >> +
>> >> +	/* Is the saved position usable? */
>> >> +	if (saved) {
>> >> +		/* Proper parent and hash? */
>> >> +		if ((parent != saved->parent) || (saved->hash != hash)) {
>> >> +			saved = NULL;
>> >
>> > name is uninitialized in this path.
>> 
>> It is.  name is initialized to "" see above.
>> 
>
> Or when either of the conditions is true, it has resulted in some inconsistent state, right?
> So, why not terminating this session of readdir() immediately by
> returning NULL just as when off is turned out to be invalid?

What I have above is not the clearest, and in fact the logic could be
better.

The fundamental challenge is because hash collisions are possible a file
offset does not hold complete position information in a directory.

So the kernfs node that is to be read/displayed next is saved in the
struct file.  The it is tested if the saved kernfs node is usable
for finding the location in the directory.  Several things may have
gone wrong.

- Someone may have called seekdir.
- The saved kernfs node may have been renamed.
- The saved kernfs node may have been moved to a different directory in
  kernfs.
- the saved kernfs node may have been deleted.

If any of those are true the code needs to do the rbtree lookup.

If the kernfs node has been deleted or moved to a different directory we
can safely use it's name while performing the rbtree lookup.  Which in
the event of a hash collision will be more accurate in finding our old
location, and preventing the same directory entry being returned
multiple times.

Which is completely different than if the directory offset is an invalid
value that will never point to any directory entries.

Eric




Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ