In the Linux kernel, the following vulnerability has been resolved:
cifs: fix mid leak during reconnection after timeout threshold
When the number of responses with status of STATUSIOTIMEOUT exceeds a specified threshold (NUMSTATUSIOTIMEOUT), we reconnect the connection. But we do not return the mid, or the credits returned for the mid, or reduce the number of in-flight requests.
This bug could result in the server->inflight count to go bad, and also cause a leak in the mids.
This change moves the check to a few lines below where the response is decrypted, even of the response is read from the transform header. This way, the code for returning the mids can be reused.
Also, the cifsreconnect was reconnecting just the transport connection before. In case of multi-channel, this may not be what we want to do after several timeouts. Changed that to reconnect the session and the tree too.
Also renamed NUMSTATUSIOTIMEOUT to a more appropriate name MAXSTATUSIOTIMEOUT.
The namelen variable in CIFSFindNext is a signed int that gets set to the resumenamelen in the cifssearchinfo. The resumenamelen 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 PATHMAX check later in CIFSFindNext. The namelen 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 namelen an unsigned value in CIFSFindNext.
http://www.spinics.net/lists/linux-cifs/msg03950.html
Acknowledgements:
Red Hat would like to thank Darren Lavender for reporting this issue.
In the Linux kernel, the following vulnerability has been resolved:
cifs: fix handlecache and multiuser
In multiuser each individual user has their own tcon structure for the share and thus their own handle for a cached directory. When we umount such a share we much make sure to release the pinned down dentry for each such tcon and not just the master tcon.
Otherwise we will get nasty warnings on umount that dentries are still in use: [ 3459.590047] BUG: Dentry 00000000115c6f41{i=12000000019d95,n=/} still in use\ (2) [unmount of cifs cifs] ... [ 3459.590492] Call Trace: [ 3459.590500] dwalk+0x61/0x2a0 [ 3459.590518] ? shrinklockdentry.part.0+0xe0/0xe0 [ 3459.590526] shrinkdcacheforumount+0x49/0x110 [ 3459.590535] genericshutdownsuper+0x1a/0x110 [ 3459.590542] killanonsuper+0x14/0x30 [ 3459.590549] cifskillsb+0xf5/0x104 [cifs] [ 3459.590773] deactivatelockedsuper+0x36/0xa0 [ 3459.590782] cleanupmnt+0x131/0x190 [ 3459.590789] taskworkrun+0x5c/0x90 [ 3459.590798] exittousermodeloop+0x151/0x160 [ 3459.590809] exittousermodeprepare+0x83/0xd0 [ 3459.590818] syscallexittousermode+0x12/0x30 [ 3459.590828] dosyscall64+0x48/0x90 [ 3459.590833] entrySYSCALL64afterhwframe+0x44/0xae