linux-toradex.git/fs/cifs, branch v3.0.18

CIFS: Fix DFS handling in cifs_get_file_info

2011-11-11T17:35:11+00:00

commit 42274bb22afc3e877ae5abed787b0b09d7dede52 upstream.

We should call cifs_all_info_to_fattr in rc == 0 case only.

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

CIFS: Fix incorrect max RFC1002 write size value

2011-11-11T17:35:11+00:00

commit 94443f43404239c2a6dc4252a7cb9e77f5b1eb6e upstream.

..the length field has only 17 bits.

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

CIFS: Fix ERR_PTR dereference in cifs_get_root

2011-10-25T05:10:15+00:00

commit 5b980b01212199833ee8023770fa4cbf1b85e9f4 upstream.

move it to the beginning of the loop.

Signed-off-by: Pavel Shilovsky 
Reviewed-by: Jeff Layton 
Signed-off-by: Steve French 
Cc: Josh Boyer 
Signed-off-by: Greg Kroah-Hartman

Fix the conflict between rwpidforward and rw mount options

2011-10-03T18:40:35+00:00

commit c9c7fa0064f4afe1d040e72f24c2256dd8ac402d upstream.

Both these options are started with "rw" - that's why the first one
isn't switched on even if it is specified. Fix this by adding a length
check for "rw" option check.

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

cifs: fix possible memory corruption in CIFSFindNext

2011-10-03T18:40:35+00:00

commit 9438fabb73eb48055b58b89fc51e0bc4db22fabd upstream.

The name_len variable in CIFSFindNext is a signed int that gets set to
the resume_name_len in the cifs_search_info. The resume_name_len however
is unsigned and for some infolevels is populated directly from a 32 bit
value sent by the server.

If the server sends a very large value for this, then that value could
look negative when converted to a signed int. That would make that
value pass the PATH_MAX check later in CIFSFindNext. The name_len would
then be used as a length value for a memcpy. It would then be treated
as unsigned again, and the memcpy scribbles over a ton of memory.

Fix this by making the name_len an unsigned value in CIFSFindNext.

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

possible memory corruption on mount

2011-08-29T20:29:07+00:00

commit 13589c437daf4c8e429b3236c0b923de1c9420d8 upstream.

CIFS cleanup_volume_info_contents() looks like having a memory
corruption problem.
When UNCip is set to "&vol->UNC[2]" in cifs_parse_mount_options(), it
should not be kfree()-ed in cleanup_volume_info_contents().

Introduced in commit b946845a9dc523c759cae2b6a0f6827486c3221a

Signed-off-by: J.R. Okajima 
Reviewed-by: Jeff Layton 
Signed-off-by: Steve French 
Signed-off-by: Greg Kroah-Hartman

cifs: demote cERROR in build_path_from_dentry to cFYI

2011-08-29T20:29:06+00:00

commit fa71f447065f676157ba6a2c121ba419818fc559 upstream.

Running the cthon tests on a recent kernel caused this message to pop
occasionally:

    CIFS VFS: did not end path lookup where expected namelen is 0

Some added debugging showed that namelen and dfsplen were both 0 when
this occurred. That means that the read_seqretry returned true.

Assuming that the comment inside the if statement is true, this should
be harmless and just means that we raced with a rename. If that is the
case, then there's no need for alarm and we can demote this to cFYI.

While we're at it, print the dfsplen too so that we can see what
happened here if the message pops during debugging.

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

cifs: convert prefixpath delimiters in cifs_build_path_to_root

2011-08-16T01:31:36+00:00

commit f9e8c45002cacad536b338dfa9e910e341a49c31 upstream.

Regression from 2.6.39...

The delimiters in the prefixpath are not being converted based on
whether posix paths are in effect. Fixes:

    https://bugzilla.redhat.com/show_bug.cgi?id=727834

Reported-and-Tested-by: Iain Arnell 
Reported-by: Patrick Oltmann 
Cc: Pavel Shilovsky 
Signed-off-by: Jeff Layton 
Signed-off-by: Steve French 
Signed-off-by: Greg Kroah-Hartman

cifs: cope with negative dentries in cifs_get_root

2011-08-16T01:31:36+00:00

commit 80975d21aae2136ccae1ce914a1602dc1d8b0795 upstream.

The loop around lookup_one_len doesn't handle the case where it might
return a negative dentry, which can cause an oops on the next pass
through the loop. Check for that and break out of the loop with an
error of -ENOENT if there is one.

Fixes the panic reported here:

    https://bugzilla.redhat.com/show_bug.cgi?id=727927

Reported-by: TR Bentley 
Reported-by: Iain Arnell 
Cc: Al Viro 
Signed-off-by: Jeff Layton 
Signed-off-by: Steve French 
Signed-off-by: Greg Kroah-Hartman

CIFS: Fix missing a decrement of inFlight value

2011-08-16T01:31:36+00:00

commit 0193e072268fe62c4b19ad4b05cd0d4b23c43bb9 upstream.

if we failed on getting mid entry in cifs_call_async.

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