linux-stable.git/fs/cifs, branch linux-4.1.y

cifs: do not allow creating sockets except with SMB1 posix exensions

2018-05-23T01:36:35+00:00

[ Upstream commit 1d0cffa674cfa7d185a302c8c6850fc50b893bed ]

RHBZ: 1453123

Since at least the 3.10 kernel and likely a lot earlier we have
not been able to create unix domain sockets in a cifs share
when mounted using the SFU mount option (except when mounted
with the cifs unix extensions to Samba e.g.)
Trying to create a socket, for example using the af_unix command from
xfstests will cause :
BUG: unable to handle kernel NULL pointer dereference at 00000000
00000040

Since no one uses or depends on being able to create unix domains sockets
on a cifs share the easiest fix to stop this vulnerability is to simply
not allow creation of any other special files than char or block devices
when sfu is used.

Added update to Ronnie's patch to handle a tcon link leak, and
to address a buf leak noticed by Gustavo and Colin.

Acked-by: Gustavo A. R. Silva 
CC:  Colin Ian King 
Reviewed-by: Pavel Shilovsky 
Reported-by: Eryu Guan 
Signed-off-by: Ronnie Sahlberg 
Signed-off-by: Steve French 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

SMB2: Fix share type handling

2018-05-23T01:36:23+00:00

[ Upstream commit cd1230070ae1c12fd34cf6a557bfa81bf9311009 ]

In fs/cifs/smb2pdu.h, we have:
#define SMB2_SHARE_TYPE_DISK    0x01
#define SMB2_SHARE_TYPE_PIPE    0x02
#define SMB2_SHARE_TYPE_PRINT   0x03

Knowing that, with the current code, the SMB2_SHARE_TYPE_PRINT case can
never trigger and printer share would be interpreted as disk share.

So, test the ShareType value for equality instead.

Fixes: faaf946a7d5b ("CIFS: Add tree connect/disconnect capability for SMB2")
Signed-off-by: Christophe JAILLET 
Acked-by: Aurelien Aptel 
Signed-off-by: Steve French 
Signed-off-by: Sasha Levin

CIFS: silence lockdep splat in cifs_relock_file()

2018-05-23T01:36:23+00:00

[ Upstream commit 560d388950ceda5e7c7cdef7f3d9a8ff297bbf9d ]

cifs_relock_file() can perform a down_write() on the inode's lock_sem even
though it was already performed in cifs_strict_readv().  Lockdep complains
about this.  AFAICS, there is no problem here, and lockdep just needs to be
told that this nesting is OK.

 =============================================
 [ INFO: possible recursive locking detected ]
 4.11.0+ #20 Not tainted
 ---------------------------------------------
 cat/701 is trying to acquire lock:
  (&cifsi->lock_sem){++++.+}, at: cifs_reopen_file+0x7a7/0xc00

 but task is already holding lock:
  (&cifsi->lock_sem){++++.+}, at: cifs_strict_readv+0x177/0x310

 other info that might help us debug this:
  Possible unsafe locking scenario:

        CPU0
        ----
   lock(&cifsi->lock_sem);
   lock(&cifsi->lock_sem);

  *** DEADLOCK ***

  May be due to missing lock nesting notation

 1 lock held by cat/701:
  #0:  (&cifsi->lock_sem){++++.+}, at: cifs_strict_readv+0x177/0x310

 stack backtrace:
 CPU: 0 PID: 701 Comm: cat Not tainted 4.11.0+ #20
 Call Trace:
  dump_stack+0x85/0xc2
  __lock_acquire+0x17dd/0x2260
  ? trace_hardirqs_on_thunk+0x1a/0x1c
  ? preempt_schedule_irq+0x6b/0x80
  lock_acquire+0xcc/0x260
  ? lock_acquire+0xcc/0x260
  ? cifs_reopen_file+0x7a7/0xc00
  down_read+0x2d/0x70
  ? cifs_reopen_file+0x7a7/0xc00
  cifs_reopen_file+0x7a7/0xc00
  ? printk+0x43/0x4b
  cifs_readpage_worker+0x327/0x8a0
  cifs_readpage+0x8c/0x2a0
  generic_file_read_iter+0x692/0xd00
  cifs_strict_readv+0x29f/0x310
  generic_file_splice_read+0x11c/0x1c0
  do_splice_to+0xa5/0xc0
  splice_direct_to_actor+0xfa/0x350
  ? generic_pipe_buf_nosteal+0x10/0x10
  do_splice_direct+0xb5/0xe0
  do_sendfile+0x278/0x3a0
  SyS_sendfile64+0xc4/0xe0
  entry_SYSCALL_64_fastpath+0x1f/0xbe

Signed-off-by: Rabin Vincent 
Acked-by: Pavel Shilovsky 
Signed-off-by: Steve French 
Signed-off-by: Sasha Levin

cifs: small underflow in cnvrtDosUnixTm()

2018-05-23T01:33:51+00:00

[ Upstream commit 564277eceeca01e02b1ef3e141cfb939184601b4 ]

January is month 1.  There is no zero-th month.  If someone passes a
zero month then it means we read from one space before the start of the
total_days_of_prev_months[] array.

We may as well also be strict about days as well.

Fixes: 1bd5bbcb6531 ("[CIFS] Legacy time handling for Win9x and OS/2 part 1")
Signed-off-by: Dan Carpenter 
Signed-off-by: Steve French 
Signed-off-by: Sasha Levin

CIFS: Enable encryption during session setup phase

2018-05-23T01:33:48+00:00

[ Upstream commit cabfb3680f78981d26c078a26e5c748531257ebb ]

In order to allow encryption on SMB connection we need to exchange
a session key and generate encryption and decryption keys.

Signed-off-by: Pavel Shilovsky 
Signed-off-by: Sasha Levin

SMB3: Validate negotiate request must always be signed

2018-05-23T01:33:48+00:00

[ Upstream commit 4587eee04e2ac7ac3ac9fa2bc164fb6e548f99cd ]

According to MS-SMB2 3.2.55 validate_negotiate request must
always be signed. Some Windows can fail the request if you send it unsigned

See kernel bugzilla bug 197311

CC: Stable 
Acked-by: Ronnie Sahlberg 
Signed-off-by: Steve French 
Signed-off-by: Sasha Levin

CIFS: zero sensitive data when freeing

2018-03-01T03:09:50+00:00

[ Upstream commit 97f4b7276b829a8927ac903a119bef2f963ccc58 ]

also replaces memset()+kfree() by kzfree().

Signed-off-by: Aurelien Aptel 
Signed-off-by: Steve French 
Reviewed-by: Pavel Shilovsky 
Cc: 
Signed-off-by: Sasha Levin

cifs: Fix autonegotiate security settings mismatch

2018-03-01T03:09:50+00:00

[ Upstream commit 9aca7e454415f7878b28524e76bebe1170911a88 ]

Autonegotiation gives a security settings mismatch error if the SMB
server selects an SMBv3 dialect that isn't SMB3.02. The exact error is
"protocol revalidation - security settings mismatch".
This can be tested using Samba v4.2 or by setting the global Samba
setting max protocol = SMB3_00.

The check that fails in smb3_validate_negotiate is the dialect
verification of the negotiate info response. This is because it tries
to verify against the protocol_id in the global smbdefault_values. The
protocol_id in smbdefault_values is SMB3.02.
In SMB2_negotiate the protocol_id in smbdefault_values isn't updated,
it is global so it probably shouldn't be, but server->dialect is.

This patch changes the check in smb3_validate_negotiate to use
server->dialect instead of server->vals->protocol_id. The patch works
with autonegotiate and when using a specific version in the vers mount
option.

Signed-off-by: Daniel N Pettersson 
Signed-off-by: Steve French 
CC: Stable 
Signed-off-by: Sasha Levin

cifs: Fix missing put_xid in cifs_file_strict_mmap

2018-03-01T03:09:50+00:00

[ Upstream commit f04a703c3d613845ae3141bfaf223489de8ab3eb ]

If cifs_zap_mapping() returned an error, we would return without putting
the xid that we got earlier.  Restructure cifs_file_strict_mmap() and
cifs_file_mmap() to be more similar to each other and have a single
point of return that always puts the xid.

Signed-off-by: Matthew Wilcox 
Signed-off-by: Steve French 
CC: Stable 
Signed-off-by: Sasha Levin

cifs: check MaxPathNameComponentLength != 0 before using it

2017-12-07T02:19:53+00:00

[ Upstream commit f74bc7c6679200a4a83156bb89cbf6c229fe8ec0 ]

And fix tcon leak in error path.

Signed-off-by: Ronnie Sahlberg 
Signed-off-by: Steve French 
CC: Stable 
Reviewed-by: David Disseldorp 
Signed-off-by: Sasha Levin