summaryrefslogtreecommitdiffstats
path: root/fs/cifs/smbencrypt.c
diff options
context:
space:
mode:
authorPavel Shilovsky <pshilov@microsoft.com>2016-11-29 20:31:23 +0100
committerPavel Shilovsky <pshilov@microsoft.com>2016-12-05 21:52:01 +0100
commit96a988ffeb90dba33a71c3826086fe67c897a183 (patch)
treeaeb1443b368e35a1af1bf5a51a55997eb5124371 /fs/cifs/smbencrypt.c
parentCIFS: Fix a possible memory corruption during reconnect (diff)
downloadlinux-96a988ffeb90dba33a71c3826086fe67c897a183.tar.xz
linux-96a988ffeb90dba33a71c3826086fe67c897a183.zip
CIFS: Fix a possible double locking of mutex during reconnect
With the current code it is possible to lock a mutex twice when a subsequent reconnects are triggered. On the 1st reconnect we reconnect sessions and tcons and then persistent file handles. If the 2nd reconnect happens during the reconnecting of persistent file handles then the following sequence of calls is observed: cifs_reopen_file -> SMB2_open -> small_smb2_init -> smb2_reconnect -> cifs_reopen_persistent_file_handles -> cifs_reopen_file (again!). So, we are trying to acquire the same cfile->fh_mutex twice which is wrong. Fix this by moving reconnecting of persistent handles to the delayed work (smb2_reconnect_server) and submitting this work every time we reconnect tcon in SMB2 commands handling codepath. This can also lead to corruption of a temporary file list in cifs_reopen_persistent_file_handles() because we can recursively call this function twice. Cc: Stable <stable@vger.kernel.org> # v4.9+ Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
Diffstat (limited to 'fs/cifs/smbencrypt.c')
0 files changed, 0 insertions, 0 deletions