kernel.git/fs/cifs, branch linux-5.12.y

cifs: Do not use the original cruid when following DFS links for multiuser mounts

2021-07-20T14:02:00Z

commit 50630b3f1ada0bf412d3f28e73bac310448d9d6f upstream. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=213565 cruid should only be used for the initial mount and after this we should use the current users credentials. Ignore the original cruid mount argument when creating a new context for a multiuser mount following a DFS link. Fixes: 24e0a1eff9e2 ("cifs: switch to new mount api") Cc: stable@vger.kernel.org # 5.11+ Reported-by: Xiaoli Feng Signed-off-by: Ronnie Sahlberg Reviewed-by: Paulo Alcantara (SUSE) Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman

cifs: handle reconnect of tcon when there is no cached dfs referral

2021-07-20T14:02:00Z

commit 507345b5ae6a57b7ecd7550ff39282ed20de7b8d upstream. When there is no cached DFS referral of tcon->dfs_path, then reconnect to same share. Signed-off-by: Paulo Alcantara (SUSE) Cc: Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman

cifs: use the expiry output of dns_query to schedule next resolution

2021-07-20T14:02:00Z

commit 506c1da44fee32ba1d3a70413289ad58c772bba6 upstream. We recently fixed DNS resolution of the server hostname during reconnect. However, server IP address may change, even when the old one continues to server (although sub-optimally). We should schedule the next DNS resolution based on the TTL of the DNS record used for the last resolution. This way, we resolve the server hostname again when a DNS record expires. Signed-off-by: Shyam Prasad N Reviewed-by: Paulo Alcantara (SUSE) Cc: # v5.11+ Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman

cifs: fix missing spinlock around update to ses->status

2021-07-14T14:59:28Z

[ Upstream commit 0060a4f28a9ef45ae8163c0805e944a2b1546762 ] In the other places where we update ses->status we protect the updates via GlobalMid_Lock. So to be consistent add the same locking around it in cifs_put_smb_ses where it was missing. Addresses-Coverity: 1268904 ("Data race condition") Signed-off-by: Steve French Signed-off-by: Sasha Levin

smb3: fix possible access to uninitialized pointer to DACL

2021-07-14T14:59:28Z

[ Upstream commit a5628263a9f8d47d9a1548fe9d5d75ba4423a735 ] dacl_ptr can be null so we must check for it everywhere it is used in build_sec_desc. Addresses-Coverity: 1475598 ("Explicit null dereference") Signed-off-by: Steve French Signed-off-by: Sasha Levin

smb3: fix uninitialized value for port in witness protocol move

2021-07-14T14:59:27Z

[ Upstream commit ff93b71a3eff25fe9d4364ef13b6e01d935600c6 ] Although in practice this can not occur (since IPv4 and IPv6 are the only two cases currently supported), it is cleaner to avoid uninitialized variable warnings. Addresses smatch warning: fs/cifs/cifs_swn.c:468 cifs_swn_store_swn_addr() error: uninitialized symbol 'port'. Reported-by: kernel test robot Reported-by: Dan Carpenter CC: Samuel Cabrero Signed-off-by: Steve French Signed-off-by: Sasha Levin

cifs: fix check of dfs interlinks

2021-07-14T14:59:27Z

[ Upstream commit 889c2a700799f3b6f82210925e1faf4a9b833c4a ] Interlink is a special type of DFS link that resolves to a different DFS domain-based namespace. To determine whether it is an interlink or not, check if ReferralServers and StorageServers bits are set to 1 and 0 respectively in ReferralHeaderFlags, as specified in MS-DFSC 3.1.5.4.5 Determining Whether a Referral Response is an Interlink. Signed-off-by: Paulo Alcantara (SUSE) Reviewed-by: Aurelien Aptel Signed-off-by: Steve French Signed-off-by: Sasha Levin

cifs: improve fallocate emulation

2021-07-14T14:59:27Z

[ Upstream commit 966a3cb7c7db786452a87afdc3b48858fc4d4d6b ] RHBZ: 1866684 We don't have a real fallocate in the SMB2 protocol so we used to emulate fallocate by simply switching the file to become non-sparse. But as that could potantially consume a lot more data than we intended to fallocate (large sparse file and fallocating a thin slice in the middle) we would only do this IFF the fallocate request was for virtually the entire file. This patch improves this and starts allowing us to fallocate smaller chunks of a file by overwriting the region with 0, for the parts that are unallocated. The method used is to first query the server for FSCTL_QUERY_ALLOCATED_RANGES to find what is unallocated in the fallocate range and then to only overwrite-with-zero the unallocated ranges to fill in the holes. As overwriting-with-zero is different from just allocating blocks, and potentially much more expensive, we limit this to only allow fallocate ranges up to 1Mb in size. Reported-by: kernel test robot Signed-off-by: Ronnie Sahlberg Acked-by: Aurelien Aptel Acked-by: Paulo Alcantara (SUSE) Signed-off-by: Steve French Signed-off-by: Sasha Levin

SMB3: incorrect file id in requests compounded with open

2021-06-03T07:09:43Z

[ Upstream commit c0d46717b95735b0eacfddbcca9df37a49de9c7a ] See MS-SMB2 3.2.4.1.4, file ids in compounded requests should be set to 0xFFFFFFFFFFFFFFFF (we were treating it as u32 not u64 and setting it incorrectly). Signed-off-by: Steve French Reported-by: Stefan Metzmacher Reviewed-by: Shyam Prasad N Signed-off-by: Sasha Levin

cifs: set server->cipher_type to AES-128-CCM for SMB3.0

2021-06-03T07:09:23Z

commit 6d2fcfe6b517fe7cbf2687adfb0a16cdcd5d9243 upstream. SMB3.0 doesn't have encryption negotiate context but simply uses the SMB2_GLOBAL_CAP_ENCRYPTION flag. When that flag is present in the neg response cifs.ko uses AES-128-CCM which is the only cipher available in this context. cipher_type was set to the server cipher only when parsing encryption negotiate context (SMB3.1.1). For SMB3.0 it was set to 0. This means cipher_type value can be 0 or 1 for AES-128-CCM. Fix this by checking for SMB3.0 and encryption capability and setting cipher_type appropriately. Signed-off-by: Aurelien Aptel Cc: Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman