Bug 1771691

Summary: Process killed while opening a file can result in leaked open handle on the server
Product: Red Hat Enterprise Linux 8 Reporter: Frank Sorenson <fsorenso>
Component: kernelAssignee: cifs-maint
kernel sub component: CIFS QA Contact: xiaoli feng <xifeng>
Status: CLOSED ERRATA Docs Contact:
Severity: medium    
Priority: medium CC: cifs-maint, jke, jshivers, lsahlber, xzhou
Version: 8.1Keywords: Reproducer
Target Milestone: rcFlags: pm-rhel: mirror+
Target Release: 8.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: kernel-4.18.0-167.el8 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1771687 Environment:
Last Closed: 2020-04-28 16:32:33 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1771687    
Bug Blocks:    

Description Frank Sorenson 2019-11-12 19:19:06 UTC 
+++ This bug was initially created as a clone of Bug #1771687 +++

Description of problem:

If a process opening a file is killed while waiting for a SMB2_CREATE response from the server, the response may not be handled by the client, leaking an open file handle on the server.


Version-Release number of selected component (if applicable):

all kernels (RHEL 7, RHEL 8, upstream)


How reproducible:

easy


Steps to Reproduce:

# mount //vm3/user1 /mnt/vm3 -overs=3,sec=ntlmssp,credentials=/root/.user1_smb_creds
# cd /mnt/vm3
# echo foo > foo

# for i in {1..100} ; do cat foo >/dev/null 2>&1 & sleep 0.0001 ; kill -9 $! ; done

(increase count if necessary--100 appears sufficient to cause multiple leaked file handles)


Actual results:

the client stops waiting for the response, and outputs the following message when the response arrives:
    CIFS VFS: Close unmatched open

the server leaks an open file handle--can be seen using samba, with the following:

# smbstatus | grep -i Locked -A1000
Locked files:
Pid          Uid        DenyMode   Access      R/W        Oplock           SharePath   Name   Time
--------------------------------------------------------------------------------------------------
25936        501        DENY_NONE  0x80        RDONLY     NONE             /home/user1   .   Tue Nov 12 12:29:24 2019
25936        501        DENY_NONE  0x80        RDONLY     NONE             /home/user1   .   Tue Nov 12 12:29:24 2019
25936        501        DENY_NONE  0x120089    RDONLY     LEASE(RWH)       /home/user1   foo   Tue Nov 12 12:29:24 2019
25936        501        DENY_NONE  0x120089    RDONLY     LEASE(RWH)       /home/user1   foo   Tue Nov 12 12:29:24 2019
25936        501        DENY_NONE  0x120089    RDONLY     LEASE(RWH)       /home/user1   foo   Tue Nov 12 12:29:24 2019
25936        501        DENY_NONE  0x120089    RDONLY     LEASE(RWH)       /home/user1   foo   Tue Nov 12 12:29:24 2019
25936        501        DENY_NONE  0x120089    RDONLY     LEASE(RWH)       /home/user1   foo   Tue Nov 12 12:29:24 2019


Expected results:

the client handles the open response, and then closes the file (can the create/open be canceled?)


Additional info:

--- Additional comment from RHEL Product and Program Management on 2019-11-12 13:14:37 CST ---

Since this bug report was entered in Red Hat Bugzilla, the release flag has been set to ? to ensure that it is properly evaluated for this release.
Comment 1 Jacob Shivers 2019-12-03 18:04:42 UTC 
Patches addressing this behavior were submitted upstream after merging from cifs-next:

9150c3adbf24d77cfba37f03639d4a908ca4ac25 CIFS: Close open handle after interrupted close
7b71843fa7028475b052107664cbe120156a2cfc CIFS: Do not miss cancelled OPEN responses
86a7964be7afaf3df6b64faaa10a7032d2444e51 CIFS: Fix NULL pointer dereference in mid callback

Confirmed that the behavior can not be reproduced on rawhide build 5.4.0-2.fc32.x86_64.
Comment 3 Bruno Meneguele 2019-12-16 15:38:10 UTC 
Patch(es) available on kernel-4.18.0-167.el8
Comment 11 errata-xmlrpc 2020-04-28 16:32:33 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2020:1769