<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/fs, branch linux-2.6.37.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-2.6.37.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-2.6.37.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2011-03-27T19:00:48Z</updated>
<entry>
<title>ext4: skip orphan cleanup if fs has unknown ROCOMPAT features</title>
<updated>2011-03-27T19:00:48Z</updated>
<author>
<name>Amir Goldstein</name>
<email>amir73il@gmail.com</email>
</author>
<published>2011-02-28T05:53:45Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=191095aaab76c04a1c2d410bafd2da1a6a95f476'/>
<id>urn:sha1:191095aaab76c04a1c2d410bafd2da1a6a95f476</id>
<content type='text'>
commit d39195c33bb1b5fdcb0f416e8a0b34bfdb07a027 upstream.

Orphan cleanup is currently executed even if the file system has some
number of unknown ROCOMPAT features, which deletes inodes and frees
blocks, which could be very bad for some RO_COMPAT features,
especially the SNAPSHOT feature.

This patch skips the orphan cleanup if it contains readonly compatible
features not known by this ext4 implementation, which would prevent
the fs from being mounted (or remounted) readwrite.

Signed-off-by: Amir Goldstein &lt;amir73il@users.sf.net&gt;
Signed-off-by: "Theodore Ts'o" &lt;tytso@mit.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>fs: call security_d_instantiate in d_obtain_alias V2</title>
<updated>2011-03-27T19:00:46Z</updated>
<author>
<name>Josef Bacik</name>
<email>josef@redhat.com</email>
</author>
<published>2010-11-19T01:52:55Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=6b0b6741726daad876d5443aae2ffe4efa328f01'/>
<id>urn:sha1:6b0b6741726daad876d5443aae2ffe4efa328f01</id>
<content type='text'>
commit 24ff6663ccfdaf088dfa7acae489cb11ed4f43c4 upstream.

While trying to track down some NFS problems with BTRFS, I kept noticing I was
getting -EACCESS for no apparent reason.  Eric Paris and printk() helped me
figure out that it was SELinux that was giving me grief, with the following
denial

type=AVC msg=audit(1290013638.413:95): avc:  denied  { 0x800000 } for  pid=1772
comm="nfsd" name="" dev=sda1 ino=256 scontext=system_u:system_r:kernel_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=file

Turns out this is because in d_obtain_alias if we can't find an alias we create
one and do all the normal instantiation stuff, but we don't do the
security_d_instantiate.

Usually we are protected from getting a hashed dentry that hasn't yet run
security_d_instantiate() by the parent's i_mutex, but obviously this isn't an
option there, so in order to deal with the case that a second thread comes in
and finds our new dentry before we get to run security_d_instantiate(), we go
ahead and call it if we find a dentry already.  Eric assures me that this is ok
as the code checks to see if the dentry has been initialized already so calling
security_d_instantiate() against the same dentry multiple times is ok.  With
this patch I'm no longer getting errant -EACCESS values.

Signed-off-by: Josef Bacik &lt;josef@redhat.com&gt;
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Cc: Chuck Ebbert &lt;cebbert@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>NFS: Fix a hang/infinite loop in nfs_wb_page()</title>
<updated>2011-03-27T19:00:43Z</updated>
<author>
<name>Trond Myklebust</name>
<email>Trond.Myklebust@netapp.com</email>
</author>
<published>2011-03-21T19:37:01Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=5460834c2384874904358ad2191f947a2d83ec72'/>
<id>urn:sha1:5460834c2384874904358ad2191f947a2d83ec72</id>
<content type='text'>
commit b8413f98f997bb3ed7327e6d7117e7e91ce010c3 upstream.

When one of the two waits in nfs_commit_inode() is interrupted, it
returns a non-negative value, which causes nfs_wb_page() to think
that the operation was successful causing it to busy-loop rather
than exiting.
It also causes nfs_file_fsync() to incorrectly report the file as
being successfully committed to disk.

This patch fixes both problems by ensuring that we return an error
if the attempts to wait fail.

Signed-off-by: Trond Myklebust &lt;Trond.Myklebust@netapp.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>fs: assign sb-&gt;s_bdi to default_backing_dev_info if the bdi is going away</title>
<updated>2011-03-27T19:00:31Z</updated>
<author>
<name>Jens Axboe</name>
<email>jaxboe@fusionio.com</email>
</author>
<published>2011-03-17T10:13:12Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=0a490308676cbc30594f067fec60d1bb00cd3252'/>
<id>urn:sha1:0a490308676cbc30594f067fec60d1bb00cd3252</id>
<content type='text'>
commit 95f28604a65b1c40b6c6cd95e58439cd7ded3add upstream.

We don't have proper reference counting for this yet, so we run into
cases where the device is pulled and we OOPS on flushing the fs data.
This happens even though the dirty inodes have already been
migrated to the default_backing_dev_info.

Reported-by: Torsten Hilbrich &lt;torsten.hilbrich@secunet.com&gt;
Tested-by: Torsten Hilbrich &lt;torsten.hilbrich@secunet.com&gt;
Signed-off-by: Jens Axboe &lt;jaxboe@fusionio.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>nfsd: wrong index used in inner loop</title>
<updated>2011-03-27T19:00:22Z</updated>
<author>
<name>Mi Jinlong</name>
<email>mijinlong@cn.fujitsu.com</email>
</author>
<published>2011-03-11T04:13:55Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=3c923393d39b88dd97cfc3a99899fab22518cae7'/>
<id>urn:sha1:3c923393d39b88dd97cfc3a99899fab22518cae7</id>
<content type='text'>
commit 5a02ab7c3c4580f94d13c683721039855b67cda6 upstream.

We must not use dummy for index.
After the first index, READ32(dummy) will change dummy!!!!

Signed-off-by: Mi Jinlong &lt;mijinlong@cn.fujitsu.com&gt;
[bfields@redhat.com: Trond points out READ_BUF alone is sufficient.]
Signed-off-by: J. Bruce Fields &lt;bfields@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>nfsd4: fix struct file leak</title>
<updated>2011-03-27T19:00:21Z</updated>
<author>
<name>J. Bruce Fields</name>
<email>bfields@redhat.com</email>
</author>
<published>2011-03-02T23:01:35Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=692f0703b01ec1d7f367a30c01f28f246bf30624'/>
<id>urn:sha1:692f0703b01ec1d7f367a30c01f28f246bf30624</id>
<content type='text'>
commit 0997b173609b9229ece28941c118a2a9b278796e upstream.

Make sure we properly reference count the struct files that a lock
depends on, and release them when the lock stateid is released.

This fixes a major leak of struct files when using locking over nfsv4.

Reported-by: Rick Koshi &lt;nfs-bug-report@more-right-rudder.com&gt;
Tested-by: Ivo Přikryl &lt;prikryl@eurosat.cz&gt;
Signed-off-by: J. Bruce Fields &lt;bfields@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>nfsd4: minor nfs4state.c reshuffling</title>
<updated>2011-03-27T19:00:21Z</updated>
<author>
<name>J. Bruce Fields</name>
<email>bfields@redhat.com</email>
</author>
<published>2011-03-03T04:48:33Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=d7e18902cd8c5c45fa170d76cf4b90f74743d054'/>
<id>urn:sha1:d7e18902cd8c5c45fa170d76cf4b90f74743d054</id>
<content type='text'>
commit 529d7b2a7fa31e9f7d08bc790d232c3cbe64fa24 upstream.

Minor cleanup in preparation for a bugfix--moving some code to avoid
forward references, etc.  No change in functionality.

Signed-off-by: J. Bruce Fields &lt;bfields@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>nfsd41: modify the members value of nfsd4_op_flags</title>
<updated>2011-03-27T19:00:17Z</updated>
<author>
<name>Mi Jinlong</name>
<email>mijinlong@cn.fujitsu.com</email>
</author>
<published>2011-02-18T01:08:31Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=3eb8695fb23b0ea7823736e1dae62367fe08f9bc'/>
<id>urn:sha1:3eb8695fb23b0ea7823736e1dae62367fe08f9bc</id>
<content type='text'>
commit 5ece3cafbd88d4da5c734e1810c4a2e6474b57b2 upstream.

The members of nfsd4_op_flags, (ALLOWED_WITHOUT_FH | ALLOWED_ON_ABSENT_FS)
equals to  ALLOWED_AS_FIRST_OP, maybe that's not what we want.

OP_PUTROOTFH with op_flags = ALLOWED_WITHOUT_FH | ALLOWED_ON_ABSENT_FS,
can't appears as the first operation with out SEQUENCE ops.

This patch modify the wrong value of ALLOWED_WITHOUT_FH etc which
was introduced by f9bb94c4.

Reviewed-by: Benny Halevy &lt;bhalevy@panasas.com&gt;
Signed-off-by: Mi Jinlong &lt;mijinlong@cn.fujitsu.com&gt;
Signed-off-by: J. Bruce Fields &lt;bfields@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>proc: protect mm start_code/end_code in /proc/pid/stat</title>
<updated>2011-03-27T19:00:16Z</updated>
<author>
<name>Kees Cook</name>
<email>kees.cook@canonical.com</email>
</author>
<published>2011-03-23T23:42:53Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=75f0384c11f783b1cb42cc6515f5058b1f807b7d'/>
<id>urn:sha1:75f0384c11f783b1cb42cc6515f5058b1f807b7d</id>
<content type='text'>
commit 5883f57ca0008ffc93e09cbb9847a1928e50c6f3 upstream.

While mm-&gt;start_stack was protected from cross-uid viewing (commit
f83ce3e6b02d5 ("proc: avoid information leaks to non-privileged
processes")), the start_code and end_code values were not.  This would
allow the text location of a PIE binary to leak, defeating ASLR.

Note that the value "1" is used instead of "0" for a protected value since
"ps", "killall", and likely other readers of /proc/pid/stat, take
start_code of "0" to mean a kernel thread and will misbehave.  Thanks to
Brad Spengler for pointing this out.

Addresses CVE-2011-0726

Signed-off-by: Kees Cook &lt;kees.cook@canonical.com&gt;
Cc: Alexey Dobriyan &lt;adobriyan@gmail.com&gt;
Cc: David Howells &lt;dhowells@redhat.com&gt;
Cc: Eugene Teo &lt;eugeneteo@kernel.sg&gt;
Cc: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
Cc: Brad Spengler &lt;spender@grsecurity.net&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>procfs: fix /proc/&lt;pid&gt;/maps heap check</title>
<updated>2011-03-27T19:00:16Z</updated>
<author>
<name>Aaro Koskinen</name>
<email>aaro.koskinen@nokia.com</email>
</author>
<published>2011-03-23T23:42:50Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=a2fc857cbbc10ce76db11a7a92a9c3e62b1f1b1b'/>
<id>urn:sha1:a2fc857cbbc10ce76db11a7a92a9c3e62b1f1b1b</id>
<content type='text'>
commit 0db0c01b53a1a421513f91573241aabafb87802a upstream.

The current code fails to print the "[heap]" marking if the heap is split
into multiple mappings.

Fix the check so that the marking is displayed in all possible cases:
	1. vma matches exactly the heap
	2. the heap vma is merged e.g. with bss
	3. the heap vma is splitted e.g. due to locked pages

Test cases. In all cases, the process should have mapping(s) with
[heap] marking:

	(1) vma matches exactly the heap

	#include &lt;stdio.h&gt;
	#include &lt;unistd.h&gt;
	#include &lt;sys/types.h&gt;

	int main (void)
	{
		if (sbrk(4096) != (void *)-1) {
			printf("check /proc/%d/maps\n", (int)getpid());
			while (1)
				sleep(1);
		}
		return 0;
	}

	# ./test1
	check /proc/553/maps
	[1] + Stopped                    ./test1
	# cat /proc/553/maps | head -4
	00008000-00009000 r-xp 00000000 01:00 3113640    /test1
	00010000-00011000 rw-p 00000000 01:00 3113640    /test1
	00011000-00012000 rw-p 00000000 00:00 0          [heap]
	4006f000-40070000 rw-p 00000000 00:00 0

	(2) the heap vma is merged

	#include &lt;stdio.h&gt;
	#include &lt;unistd.h&gt;
	#include &lt;sys/types.h&gt;

	char foo[4096] = "foo";
	char bar[4096];

	int main (void)
	{
		if (sbrk(4096) != (void *)-1) {
			printf("check /proc/%d/maps\n", (int)getpid());
			while (1)
				sleep(1);
		}
		return 0;
	}

	# ./test2
	check /proc/556/maps
	[2] + Stopped                    ./test2
	# cat /proc/556/maps | head -4
	00008000-00009000 r-xp 00000000 01:00 3116312    /test2
	00010000-00012000 rw-p 00000000 01:00 3116312    /test2
	00012000-00014000 rw-p 00000000 00:00 0          [heap]
	4004a000-4004b000 rw-p 00000000 00:00 0

	(3) the heap vma is splitted (this fails without the patch)

	#include &lt;stdio.h&gt;
	#include &lt;unistd.h&gt;
	#include &lt;sys/mman.h&gt;
	#include &lt;sys/types.h&gt;

	int main (void)
	{
		if ((sbrk(4096) != (void *)-1) &amp;&amp; !mlockall(MCL_FUTURE) &amp;&amp;
		    (sbrk(4096) != (void *)-1)) {
			printf("check /proc/%d/maps\n", (int)getpid());
			while (1)
				sleep(1);
		}
		return 0;
	}

	# ./test3
	check /proc/559/maps
	[1] + Stopped                    ./test3
	# cat /proc/559/maps|head -4
	00008000-00009000 r-xp 00000000 01:00 3119108    /test3
	00010000-00011000 rw-p 00000000 01:00 3119108    /test3
	00011000-00012000 rw-p 00000000 00:00 0          [heap]
	00012000-00013000 rw-p 00000000 00:00 0          [heap]

It looks like the bug has been there forever, and since it only results in
some information missing from a procfile, it does not fulfil the -stable
"critical issue" criteria.

Signed-off-by: Aaro Koskinen &lt;aaro.koskinen@nokia.com&gt;
Reviewed-by: KOSAKI Motohiro &lt;kosaki.motohiro@jp.fujitsu.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
</feed>
