<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/git/stable/linux-stable.git/fs, branch linux-2.6.15.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<id>https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/atom?h=linux-2.6.15.y</id>
<link rel='self' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/atom?h=linux-2.6.15.y'/>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/'/>
<updated>2006-03-28T07:00:23+00:00</updated>
<entry>
<title>[PATCH] Fix ext2 readdir f_pos re-validation logic</title>
<updated>2006-03-28T07:00:23+00:00</updated>
<author>
<name>Al Viro</name>
<email>viro@ftp.linux.org.uk</email>
</author>
<published>2006-03-15T21:41:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=6d4da66240b9fec065933928043b1365f97ab724'/>
<id>urn:sha1:6d4da66240b9fec065933928043b1365f97ab724</id>
<content type='text'>
This fixes not one, but _two_, silly (but admittedly hard to hit) bugs
in the ext2 filesystem "readdir()" function.  It also cleans up the code
to avoid the unnecessary goto mess.

The bugs were related to re-valiating the f_pos value after somebody had
either done an "lseek()" on the directory to an invalid offset, or when
the offset had become invalid due to a file being unlinked in the
directory.  The code would not only set the f_version too eagerly, it
would also not update f_pos appropriately for when the offset fixup took
place.

When that happened, we'd occasionally subsequently fail the readdir()
even when we shouldn't (no real harm done, but an ugly printk, and
obviously you would end up not necessarily seeing all entries).

Thanks to Masoud Sharbiani &lt;masouds@google.com&gt; who noticed the problem
and had a test-case for it, and also fixed up a thinko in the first
version of this patch.

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Acked-by: Masoud Sharbiani &lt;masouds@google.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
Signed-off-by: Chris Wright &lt;chrisw@sous-sol.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</content>
</entry>
<entry>
<title>[PATCH] cramfs mounts provide corrupted content since 2.6.15</title>
<updated>2006-03-28T07:00:22+00:00</updated>
<author>
<name>Dave Johnson</name>
<email>djohnson@sw.starentnetworks.com</email>
</author>
<published>2006-03-06T23:42:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=1421207ba3fd53f8090f6f337ac7de57015d3a5c'/>
<id>urn:sha1:1421207ba3fd53f8090f6f337ac7de57015d3a5c</id>
<content type='text'>
Fix handling of cramfs images created by util-linux containing empty
regular files.  Images created by cramfstools 1.x were ok.

Fill out inode contents in cramfs_iget5_set() instead of get_cramfs_inode()
to prevent issues if cramfs_iget5_test() is called with I_LOCK|I_NEW still
set.

Signed-off-by: Dave Johnson &lt;djohnson+linux-kernel@sw.starentnetworks.com&gt;
Cc: Olaf Hering &lt;olh@suse.de&gt;
Cc: Chris Mason &lt;mason@suse.com&gt;
Cc: Andreas Gruenbacher &lt;agruen@suse.de&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
Signed-off-by: Chris Wright &lt;chrisw@sous-sol.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</content>
</entry>
<entry>
<title>[PATCH] compat ifconf: fix limits</title>
<updated>2006-03-28T07:00:22+00:00</updated>
<author>
<name>Randy Dunlap</name>
<email>rdunlap@xenotime.net</email>
</author>
<published>2006-03-09T01:43:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=8a3a2a3299081913c22f5d0e1ce893b781efe942'/>
<id>urn:sha1:8a3a2a3299081913c22f5d0e1ce893b781efe942</id>
<content type='text'>
A recent change to compat. dev_ifconf() in fs/compat_ioctl.c
causes ifconf data to be truncated 1 entry too early when copying it
to userspace.  The correct amount of data (length) is returned,
but the final entry is empty (zero, not filled in).
The for-loop 'i' check should use &lt;= to allow the final struct
ifreq32 to be copied.  I also used the ifconf-corruption program
in kernel bugzilla #4746 to make sure that this change does not
re-introduce the corruption.

Signed-off-by: Randy Dunlap &lt;rdunlap@xenotime.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Chris Wright &lt;chrisw@sous-sol.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</content>
</entry>
<entry>
<title>[PATCH] fs/nfs/direct.c compile fix</title>
<updated>2006-03-05T19:07:18+00:00</updated>
<author>
<name>Chris Wright</name>
<email>chrisw@sous-sol.org</email>
</author>
<published>2006-03-02T07:19:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=166f00bf649517bb377b23e668b3fd52497f63d0'/>
<id>urn:sha1:166f00bf649517bb377b23e668b3fd52497f63d0</id>
<content type='text'>
Compile fix:

fs/nfs/direct.c: In function 'nfs_get_user_pages':
fs/nfs/direct.c:110: warning: implicit declaration of function 'nfs_free_user_pages'
fs/nfs/direct.c: At top level:
fs/nfs/direct.c:127: warning: conflicting types for 'nfs_free_user_pages'
fs/nfs/direct.c:127: error: static declaration of 'nfs_free_user_pages' follows non-static declaration
fs/nfs/direct.c:110: error: previous implicit declaration of 'nfs_free_user_pages' was here

This should now be the same as fix that's going upstream.

Signed-off-by: Chris Wright &lt;chrisw@sous-sol.org&gt;
Acked-by: Trond Myklebust &lt;trond.myklebust@fys.uio.no&gt;
</content>
</entry>
<entry>
<title>[PATCH] Normal user can panic NFS client with direct I/O (CVE-2006-0555)</title>
<updated>2006-03-01T22:36:38+00:00</updated>
<author>
<name>Trond Myklebust</name>
<email>trond.myklebust@netapp.com</email>
</author>
<published>2006-02-15T05:42:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=93e3d00a9f0158e522cada1088233fad23247882'/>
<id>urn:sha1:93e3d00a9f0158e522cada1088233fad23247882</id>
<content type='text'>
This is CVE-2006-0555 and SGI bug 946529.  A normal user can panic an
NFS client and cause a local DoS with 'judicious'(?) use of O_DIRECT.

Signed-off-by: Chris Wright &lt;chrisw@sous-sol.org&gt;
</content>
</entry>
<entry>
<title>[PATCH] XFS ftruncate() bug could expose stale data (CVE-2006-0554)</title>
<updated>2006-03-01T22:36:38+00:00</updated>
<author>
<name>Mike O'Connor</name>
<email>mjo@dojo.mi.org</email>
</author>
<published>2006-02-15T05:17:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=8dcd7c19f2624b7150edd60da336da0bb5291bef'/>
<id>urn:sha1:8dcd7c19f2624b7150edd60da336da0bb5291bef</id>
<content type='text'>
This is CVE-2006-0554 and SGI bug 942658.  With certain types of
ftruncate() activity on 2.6 kernels, XFS can end up exposing stale
data off disk to a user, putting extents where holes should be.

Signed-off-by: Chris Wright &lt;chrisw@sous-sol.org&gt;
</content>
</entry>
<entry>
<title>[PATCH] x86_64: Check for bad elf entry address (CVE-2006-0741)</title>
<updated>2006-03-01T22:36:37+00:00</updated>
<author>
<name>Suresh Siddha</name>
<email>suresh.b.siddha@intel.com</email>
</author>
<published>2006-02-26T03:34:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=5a62d3406ddd87a26d706d0b3019f4a1872713da'/>
<id>urn:sha1:5a62d3406ddd87a26d706d0b3019f4a1872713da</id>
<content type='text'>
Fixes a local DOS on Intel systems that lead to an endless
recursive fault.  AMD machines don't seem to be affected.

Signed-off-by: Suresh Siddha &lt;suresh.b.siddha@intel.com&gt;
Signed-off-by: Andi Kleen &lt;ak@suse.de&gt;
Signed-off-by: Chris Wright &lt;chrisw@sous-sol.org&gt;
</content>
</entry>
<entry>
<title>[PATCH] ramfs: update dir mtime and ctime</title>
<updated>2006-03-01T22:36:36+00:00</updated>
<author>
<name>Andrew Morton</name>
<email>akpm@osdl.org</email>
</author>
<published>2006-02-24T21:04:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=b9c53139e460fa93b7b20928f8b49a3cb2432b69'/>
<id>urn:sha1:b9c53139e460fa93b7b20928f8b49a3cb2432b69</id>
<content type='text'>
Phil Marek &lt;philipp.marek@bmlv.gv.at&gt; points out that ramfs forgets to update
a directory's mtime and ctime when it is modified.

Cc: &lt;stable@kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Chris Wright &lt;chrisw@sous-sol.org&gt;
</content>
</entry>
<entry>
<title>[PATCH] fix deadlock in ext2</title>
<updated>2006-03-01T22:36:35+00:00</updated>
<author>
<name>Peter Staubach</name>
<email>staubach@redhat.com</email>
</author>
<published>2006-02-17T21:52:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=8fef8ea2a1f28a7611ad0b8ff7b48ceb38db9535'/>
<id>urn:sha1:8fef8ea2a1f28a7611ad0b8ff7b48ceb38db9535</id>
<content type='text'>
Fix a deadlock possible in the ext2 file system implementation.  This
deadlock occurs when a file is removed from an ext2 file system which was
mounted with the "sync" mount option.

The problem is that ext2_xattr_delete_inode() was invoking the routine,
sync_dirty_buffer(), using a buffer head which was previously locked via
lock_buffer().  The first thing that sync_dirty_buffer() does is to lock
the buffer head that it was passed.  It does this via lock_buffer().  Oops.

The solution is to unlock the buffer head in ext2_xattr_delete_inode()
before invoking sync_dirty_buffer().  This makes the code in
ext2_xattr_delete_inode() obey the same locking rules as all other callers
of sync_dirty_buffer() in the ext2 file system implementation.

Signed-off-by: Peter Staubach &lt;staubach@redhat.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</content>
</entry>
<entry>
<title>[PATCH] fix zap_thread's ptrace related problems</title>
<updated>2006-03-01T22:36:35+00:00</updated>
<author>
<name>Oleg Nesterov</name>
<email>oleg@tv-sign.ru</email>
</author>
<published>2006-02-15T19:50:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=80a16577362b3eafa2f390d5e1ffb268464ccedb'/>
<id>urn:sha1:80a16577362b3eafa2f390d5e1ffb268464ccedb</id>
<content type='text'>
1. The tracee can go from ptrace_stop() to do_signal_stop()
   after __ptrace_unlink(p).

2. It is unsafe to __ptrace_unlink(p) while p-&gt;parent may wait
   for tasklist_lock in ptrace_detach().

Signed-off-by: Oleg Nesterov &lt;oleg@tv-sign.ru&gt;
Cc: Roland McGrath &lt;roland@redhat.com&gt;
Cc: Ingo Molnar &lt;mingo@elte.hu&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Eric W. Biederman &lt;ebiederm@xmission.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
Signed-off-by: Chris Wright &lt;chrisw@sous-sol.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</content>
</entry>
</feed>
