linux-toradex.git/fs, branch v2.6.25.20

ext[234]: Avoid printk floods in the face of directory corruption (CVE-2008-3528)

2008-11-10T18:50:05+00:00

This is a trivial backport of the following upstream commits:

- bd39597cbd42a784105a04010100e27267481c67 (ext2)
- cdbf6dba28e8e6268c8420857696309470009fd9 (ext3)
- 9d9f177572d9e4eba0f2e18523b44f90dd51fe74 (ext4)

This addresses CVE-2008-3528

ext[234]: Avoid printk floods in the face of directory corruption

Note: some people thinks this represents a security bug, since it
might make the system go away while it is printing a large number of
console messages, especially if a serial console is involved.  Hence,
it has been assigned CVE-2008-3528, but it requires that the attacker
either has physical access to your machine to insert a USB disk with a
corrupted filesystem image (at which point why not just hit the power
button), or is otherwise able to convince the system administrator to
mount an arbitrary filesystem image (at which point why not just
include a setuid shell or world-writable hard disk device file or some
such).  Me, I think they're just being silly. --tytso

Signed-off-by: Eric Sandeen 
Signed-off-by: "Theodore Ts'o" 
Cc: linux-ext4@vger.kernel.org
Cc: Eugene Teo 
Signed-off-by: Greg Kroah-Hartman

Don't allow splice() to files opened with O_APPEND

2008-10-22T21:05:15+00:00

commit efc968d450e013049a662d22727cf132618dcb2f upstream

This is debatable, but while we're debating it, let's disallow the
combination of splice and an O_APPEND destination.

It's not entirely clear what the semantics of O_APPEND should be, and
POSIX apparently expects pwrite() to ignore O_APPEND, for example.  So
we could make up any semantics we want, including the old ones.

But Miklos convinced me that we should at least give it some thought,
and that accepting writes at arbitrary offsets is wrong at least for
IS_APPEND() files (which always have O_APPEND set, even if the reverse
isn't true: you can obviously have O_APPEND set on a regular file).

So disallow O_APPEND entirely for now.  I doubt anybody cares, and this
way we have one less gray area to worry about.

Reported-and-argued-for-by: Miklos Szeredi 
Acked-by: Jens Axboe 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

CIFS: make sure we have the right resume info before calling CIFSFindNext

2008-10-22T21:05:14+00:00

commit 0752f1522a9120f731232919f7ad904e9e22b8ce upstream

When we do a seekdir() or equivalent, we usually end up doing a
FindFirst call and then call FindNext until we get to the offset that we
want. The problem is that when we call FindNext, the code usually
doesn't have the proper info (mostly, the filename of the entry from the
last search) to resume the search.

Add a "last_entry" field to the cifs_search_info that points to the last
entry in the search. We calculate this pointer by using the
LastNameOffset field from the search parms that are returned. We then
use that info to do a cifs_save_resume_key before we call CIFSFindNext.

This patch allows CIFS to reliably pass the "telldir" connectathon test.

Signed-off-by: Jeff Layton 
Signed-off-by: Steve French 
Signed-off-by: Greg Kroah-Hartman

cifs: fix O_APPEND on directio mounts

2008-09-08T10:20:18+00:00

commit 838726c4756813576078203eb7e1e219db0da870 upstream

The direct I/O write codepath for CIFS is done through
cifs_user_write(). That function does not currently call
generic_write_checks() so the file position isn't being properly set
when the file is opened with O_APPEND.  It's also not doing the other
"normal" checks that should be done for a write call.

The problem is currently that when you open a file with O_APPEND on a
mount with the directio mount option, the file position is set to the
beginning of the file. This makes any subsequent writes clobber the data
in the file starting at the beginning.

This seems to fix the problem in cursory testing. It is, however
important to note that NFS disallows the combination of
(O_DIRECT|O_APPEND). If my understanding is correct, the concern is
races with multiple clients appending to a file clobbering each others'
data. Since the write model for CIFS and NFS is pretty similar in this
regard, CIFS is probably subject to the same sort of races. What's
unclear to me is why this is a particular problem with O_DIRECT and not
with buffered writes...

Regardless, disallowing O_APPEND on an entire mount is probably not
reasonable, so we'll probably just have to deal with it and reevaluate
this flag combination when we get proper support for O_DIRECT. In the
meantime this patch at least fixes the existing problem.

Signed-off-by: Jeff Layton 
Signed-off-by: Steve French 
Signed-off-by: Greg Kroah-Hartman

cramfs: fix named-pipe handling

2008-09-08T10:20:18+00:00

commit 82d63fc9e30687c055b97928942b8893ea65b0bb upstream

After commit a97c9bf33f4612e2aed6f000f6b1d268b6814f3c (fix cramfs
making duplicate entries in inode cache) in kernel 2.6.14, named-pipe
on cramfs does not work properly.

It seems the commit make all named-pipe on cramfs share their inode
(and named-pipe buffer).

Make ..._test() refuse to merge inodes with ->i_ino == 1, take inode setup
back to get_cramfs_inode() and make ->drop_inode() evict ones with ->i_ino
== 1 immediately.

Reported-by: Atsushi Nemoto 
Cc: Al Viro 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

nfsd: fix buffer overrun decoding NFSv4 acl

2008-09-08T10:20:16+00:00

commit 91b80969ba466ba4b915a4a1d03add8c297add3f upstream

The array we kmalloc() here is not large enough.

Thanks to Johann Dahm and David Richter for bug report and testing.

Signed-off-by: J. Bruce Fields 
Cc: David Richter 
Tested-by: Johann Dahm 
Signed-off-by: Greg Kroah-Hartman

CIFS: Fix compiler warning on 64-bit

2008-08-20T18:15:46+00:00

commit 04e1e0cccade330ab3715ce59234f7e3b087e246 upstream.

Signed-off-by: Steve French 
Cc: Eugene Teo 
Signed-off-by: Greg Kroah-Hartman

CIFS: if get root inode fails during mount, cleanup tree connection

2008-08-20T18:15:27+00:00

commit 2c731afb0d4ba16018b400c75665fbdb8feb2175 upstream

Signed-off-by: Steve French 
Signed-off-by: Greg Kroah-Hartman

CIFS: mount of IPC$ breaks with iget patch

2008-08-20T18:15:27+00:00

commit ad661334b8ae421154b121ee6ad3b56807adbf11 upstream

In looking at network named pipe support on cifs, I noticed that
Dave Howell's iget patch:

    iget: stop CIFS from using iget() and read_inode()

broke mounts to IPC$ (the interprocess communication share), and don't
handle the error case (when getting info on the root inode fails).

Thanks to Gunter who noted a typo in a debug line in the original
version of this patch.

CC: David Howells 
CC: Gunter Kukkukk 
Signed-off-by: Steve French 
Signed-off-by: Greg Kroah-Hartman

vfs: fix lookup on deleted directory

2008-08-06T17:11:08+00:00

commit d70b67c8bc72ee23b55381bd6a884f4796692f77 upstream

Lookup can install a child dentry for a deleted directory.  This keeps
the directory dentry alive, and the inode pinned in the cache and on
disk, even after all external references have gone away.

This isn't a big problem normally, since memory pressure or umount
will clear out the directory dentry and its children, releasing the
inode.  But for UBIFS this causes problems because its orphan area can
overflow.

Fix this by returning ENOENT for all lookups on a S_DEAD directory
before creating a child dentry.

Thanks to Zoltan Sogor for noticing this while testing UBIFS, and
Artem for the excellent analysis of the problem and testing.

Reported-by: Artem Bityutskiy 
Tested-by: Artem Bityutskiy 
Signed-off-by: Miklos Szeredi 
Signed-off-by: Al Viro 
Signed-off-by: Greg Kroah-Hartman