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

cifs: always update the inode cache with the results from a FIND_*

2012-08-01T19:26:53+00:00

commit cd60042cc1392e79410dc8de9e9c1abb38a29e57 upstream.

When we get back a FIND_FIRST/NEXT result, we have some info about the
dentry that we use to instantiate a new inode. We were ignoring and
discarding that info when we had an existing dentry in the cache.

Fix this by updating the inode in place when we find an existing dentry
and the uniqueid is the same.

Reported-and-Tested-by: Andrew Bartlett 
Reported-by: Bill Robertson 
Reported-by: Dion Edwards 
Signed-off-by: Jeff Layton 
Signed-off-by: Steve French 
Signed-off-by: Greg Kroah-Hartman

cifs: fix oops while traversing open file list (try #4)

2012-06-09T15:32:58+00:00

commit 2c0c2a08bed7a3b791f88d09d16ace56acb3dd98 upstream.

While traversing the linked list of open file handles, if the identfied
file handle is invalid, a reopen is attempted and if it fails, we
resume traversing where we stopped and cifs can oops while accessing
invalid next element, for list might have changed.

So mark the invalid file handle and attempt reopen if no
valid file handle is found in rest of the list.
If reopen fails, move the invalid file handle to the end of the list
and start traversing the list again from the begining.
Repeat this four times before giving up and returning an error if
file reopen keeps failing.

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

cifs: fix issue mounting of DFS ROOT when redirecting from one domain controller to the next

2012-04-02T16:27:17+00:00

commit 1daaae8fa4afe3df78ca34e724ed7e8187e4eb32 upstream.

This patch fixes an issue when cifs_mount receives a
STATUS_BAD_NETWORK_NAME error during cifs_get_tcon but is able to
continue after an DFS ROOT referral. In this case, the return code
variable is not reset prior to trying to mount from the system referred
to. Thus, is_path_accessible is not executed and the final DFS referral
is not performed causing a mount error.

Use case: In DNS, example.com  resolves to the secondary AD server
ad2.example.com Our primary domain controller is ad1.example.com and has
a DFS redirection set up from \\ad1\share\Users to \\files\share\Users.
Mounting \\example.com\share\Users fails.

Regression introduced by commit 724d9f1.

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

cifs: fix dentry refcount leak when opening a FIFO on lookup

2012-03-12T17:32:56+00:00

commit 5bccda0ebc7c0331b81ac47d39e4b920b198b2cd upstream.

The cifs code will attempt to open files on lookup under certain
circumstances. What happens though if we find that the file we opened
was actually a FIFO or other special file?

Currently, the open filehandle just ends up being leaked leading to
a dentry refcount mismatch and oops on umount. Fix this by having the
code close the filehandle on the server if it turns out not to be a
regular file. While we're at it, change this spaghetti if statement
into a switch too.

Reported-by: CAI Qian 
Tested-by: CAI Qian 
Reviewed-by: Shirish Pargaonkar 
Signed-off-by: Jeff Layton 
Signed-off-by: Steve French 
Signed-off-by: Greg Kroah-Hartman

cifs: Fix oops in session setup code for null user mounts

2012-02-13T19:06:09+00:00

commit de47a4176c532ef5961b8a46a2d541a3517412d3 upstream.

For null user mounts, do not invoke string length function
during session setup.

Reported-and-Tested-by: Chris Clayton 
Acked-by: Jeff Layton 
Signed-off-by: Shirish Pargaonkar 
Signed-off-by: Steve French 
Signed-off-by: Greg Kroah-Hartman

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