linux-kernel - Re: linux-next: build failure after merge of the driver-core tree

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: <m1iq6lh50h.fsf@fess.ebiederm.org>
Date:	Tue, 18 May 2010 03:35:10 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Stephen Rothwell <sfr@...b.auug.org.au>
Cc:	Greg KH <greg@...ah.com>, linux-next@...r.kernel.org,
	linux-kernel@...r.kernel.org, Al Viro <viro@...iv.linux.org.uk>
Subject: Re: linux-next: build failure after merge of the driver-core tree

Stephen Rothwell <sfr@...b.auug.org.au> writes:

> Hi Eric,
>
> On Tue, 18 May 2010 00:00:01 -0700 ebiederm@...ssion.com (Eric W. Biederman) wrote:
>>
>> Stephen what is the easiest way to get a copy of Al's tree so I can take
>> a look to see what needs to happen?
>
> It is here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6.git#for-next
>
> [The latest list of trees included in linux-next can always be found here:
> http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=blob;f=Next/Trees]

Thanks.

I will cook up a proper incremental patch after I get some sleep.  Stephen
it appears those two lines you have commented out are actually unnecessary.

We have
deactivate_super
  kill_sb aka sysfs_kill_sb
    kill_anon_super
      generic_shutdown_super
         sb_lock
         list_del(sb->s_instances)
         sb_unlock
  kfree(info)

Nothing generic stomps on s_fs_info.

Which means that if I find a superblock on sb->s_instances sb->s_fs_info
still points to a valid sysfs_super_info.

As as for the race Al mentions between sysfs_exit_ns and
sysfs_readdir, I looked and a small race has crept in.  The primary
prevention of problems is that all matching sysfs_dirents for that
namespace are required to be removed before sysfs_exit_ns is called.

What remains is the tiniest of races where a namespace structure is
freed and a new namespace structure of the same type is allocated at
the same address and sysfs_dirents for it are created, all during the
a single kernel readdir operation.  Possible with slabs, and
copy_to_user triggering a page fault.  Still the worst case is that we
tell userspace some name that it wasn't supposed to see on that mount
point.  From a userspace point of view this seems to fall under a
readdir implementations license to return some odd things if the
directory is changing during the readdir call.  Overall we do preserve
the property of returning everything that is in the directory between
opendir and the time readdir his the end of file.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/