In the Linux kernel, the following vulnerability has been resolved:

cifs: Fix the smbdresponse slab to allow usercopy

The handling of received data in the smbdirect client code involves using copytoiter() to copy data from the smbdreponse struct's packet trailer to a folioq buffer provided by netfslib that encapsulates a chunk of pagecache.

If, however, CONFIGHARDENEDUSERCOPY=y, this will result in the checks then performed in copytoiter() oopsing with something like the following:

CIFS: Attempting to mount //172.31.9.1/test CIFS: VFS: RDMA transport established usercopy: Kernel memory exposure attempt detected from SLUB object 'smbdresponse0000000091e24ea1' (offset 81, size 63)! ------------[ cut here ]------------ kernel BUG at mm/usercopy.c:102! ... RIP: 0010:usercopyabort+0x6c/0x80 ... Call Trace: <TASK> checkheapobject+0xe3/0x120 checkobjectsize+0x4dc/0x6d0 smbdrecv+0x77f/0xfe0 [cifs] cifsreadvfromsocket+0x276/0x8f0 [cifs] cifsreadfromsocket+0xcd/0x120 [cifs] cifsdemultiplexthread+0x7e9/0x2d50 [cifs] kthread+0x396/0x830 retfromfork+0x2b8/0x3b0 retfromforkasm+0x1a/0x30

The problem is that the smbdresponse slab's packet field isn't marked as being permitted for usercopy.

Fix this by passing parameters to kmemslabcreate() to indicate that copytoiter() is permitted from the packet region of the smbdresponse slab objects, less the header space.

Description of problem: From me, while creating a file on a server which supports unix extensions such as Samba, if a file is being created which does not supply nameidata (i.e. nd is null), cifs client can oops when calling cifsposixopen.

http://comments.gmane.org/gmane.linux.file-systems.cifs/5782