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

JFFS2 locking regression fix.

2007-08-22T23:23:27+00:00

Commit a491486a2087ac3dfc00efb4f838c8d684afaf54 introduced a locking
problem in JFFS2 -- we up() the alloc_sem when we weren't previously
holding it. This leads to all kinds of fun behaviour later.

There was a _reason_ for the
	if (1 /* alternative path needs testing */ ||
which the above-mentioned commit removed :)

Discovered and debugged by Giulio Fedel 

Signed-off-by: David Woodhouse 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

Reset current->pdeath_signal on SUID binary execution (CVE-2007-3848)

2007-08-21T04:32:42+00:00

This fixes a vulnerability in the "parent process death signal"
implementation discoverd by Wojciech Purczynski of COSEINC PTE Ltd.
and iSEC Security Research.

http://marc.info/?l=bugtraq&m=118711306802632&w=2

Signed-off-by: Marcel Holtmann 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

direct-io: fix error-path crashes

2007-08-15T16:25:10+00:00

Need to initialize map_bh.b_state to zero.  Otherwise, in case of a faulty
user-buffer its possible to go into dio_zero_block() and submit a page by
mistake - since it checks for buffer_new().

http://marc.info/?l=linux-kernel&m=118551339032528&w=2

akpm: Linus had a (better) patch to just do a kzalloc() in there, but it got
lost.  Probably this version is better for -stable anwyay.

Signed-off-by: Badari Pulavarty 
Acked-by: Joe Jin 
Acked-by: Zach Brown 
Cc: gurudas pai 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

sysfs: release mutex when kmalloc() failed in sysfs_open_file().

2007-08-09T21:27:46+00:00

Signed-off-by: Greg Kroah-Hartman

jbd2 commit: fix transaction dropping

2007-08-09T21:27:40+00:00

We have to check that also the second checkpoint list is non-empty before
dropping the transaction.

Signed-off-by: Jan Kara 
Cc: Chuck Ebbert 
Cc: Kirill Korotaev 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

jbd commit: fix transaction dropping

2007-08-09T21:27:40+00:00

We have to check that also the second checkpoint list is non-empty before
dropping the transaction.

Signed-off-by: Jan Kara 
Cc: Chuck Ebbert 
Cc: Kirill Korotaev 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

fs: 9p/conv.c error path fix

2007-08-09T21:27:39+00:00

When buf_check_overflow() returns != 0 we will hit kfree(ERR_PTR(err))
and it will not be happy about it.

Signed-off-by: Mariusz Kozlowski 
Cc: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

nfsd: fix possible read-ahead cache and export table corruption

2007-08-09T21:27:39+00:00

The value of nperbucket calculated here is too small--we should be rounding up
instead of down--with the result that the index j in the following loop can
overflow the raparm_hash array.  At least in my case, the next thing in memory
turns out to be export_table, so the symptoms I see are crashes caused by the
appearance of four zeroed-out export entries in the first bucket of the hash
table of exports (which were actually entries in the readahead cache, a
pointer to which had been written to the export table in this initialization
code).

It looks like the bug was probably introduced with commit
fce1456a19f5c08b688c29f00ef90fdfa074c79b ("knfsd: make the readahead params
cache SMP-friendly").

Cc: Greg Banks 
Signed-off-by: "J. Bruce Fields" 
Acked-by: NeilBrown 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

eCryptfs: ecryptfs_setattr() bugfix

2007-08-09T21:27:38+00:00

There is another bug recently introduced into the ecryptfs_setattr()
function in 2.6.22.  eCryptfs will attempt to treat special files like
regular eCryptfs files on chmod, chown, and so forth.  This leads to a NULL
pointer dereference.  This patch validates that the file is a regular file
before proceeding with operations related to the inode's crypt_stat.

Thanks to Ryusuke Konishi for finding this bug and suggesting the fix.

Signed-off-by: Michael Halcrow 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

"ext4_ext_put_in_cache" uses __u32 to receive physical block number

2007-08-09T21:27:36+00:00

Yan Zheng wrote:

> I think I found a bug in ext4/extents.c, "ext4_ext_put_in_cache" uses
> "__u32" to receive physical block number.  "ext4_ext_put_in_cache" is
> used in "ext4_ext_get_blocks", it sets ext4 inode's extent cache
> according most recently tree lookup (higher 16 bits of saved physical
> block number are always zero). when serving a mapping request,
> "ext4_ext_get_blocks" first check whether the logical block is in
> inode's extent cache. if the logical block is in the cache and the
> cached region isn't a gap, "ext4_ext_get_blocks" gets physical block
> number by using cached region's physical block number and offset in
> the cached region.  as described above, "ext4_ext_get_blocks" may
> return wrong result when there are physical block numbers bigger than
> 0xffffffff.
>

You are right.  Thanks for reporting this!

Signed-off-by: Mingming Cao 
Cc: Yan Zheng 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman