This routine is used to create an CIFS entry and the above code snippet is a check that will ensure ‘tcon->unix_ext’ (this is a Boolean flag for Linux extensions to CIFS protocol) isn’t NULL and then proceed to a capabilities check using session’s stored capabilities (through ‘tcon->ses->capabilities’) as well as the UNIX extension filesystem’s capability (using ‘tcon->fsUnixInfo.Capability’). At last, it will call cifs_posix_open() of fs/cifs/dir.c but as it was noted by Eugene Teo, the provided code in cifs_create() doesn’t perform any checks to ensure that the ‘nameidata’ pointer represented by ‘nd’ variable is a valid pointer. Because of this, if a file is created using UNIX extensions support and that file doesn’t provide any ‘nameidata’ pointer it will lead to ‘nd’ initialized to NULL and the call to cifs_posix_open() shown above will result in a NULL pointer dereference when it’ll attempt to access ‘nd->path.mnt’ to obtain the VFS mount information for that file. Here is how cifs_posix_open() uses the retrieved VFS mount structure (its 3rd argument):

Even though I haven’t tested anything yet I think that it could lead to exploitable conditions since it’s used by numerous functions that could be used to manipulate data from kernel space assuming that you can map the required pages to avoid the crash. Obviously, the vulnerability was patched simply like this: