While looking at a memory leak in cifs.ko smb3_validate_negotiate(), I came across the following worrying code:

 725         if (rsplen != sizeof(struct validate_negotiate_info_rsp)) {
 726                 cifs_dbg(VFS, "invalid protocol negotiate response size: %d\n",
 727                          rsplen);
 728 
 729                 /* relax check since Mac returns max bufsize allowed on ioctl */
 730                 if (rsplen > CIFSMaxBufSize)
 731                         return -EIO;
 732         }

Commit 7db0a6efdc3e ("SMB3: Work around mount failure when using SMB3 dialect to Macs"), means that we now permit responses which don't match sizeof(struct validate_negotiate_info_rsp), as long as they're under CIFSMaxBufSize - There's no check for undersize responses.
An undersize response results in comparisons (only) against uninitialized memory corresponding to the Dialect, SecurityMode and/or Capabilities members of struct validate_negotiate_info_rsp. E.g.

 733 
 734         /* check validate negotiate info response matches what we got earlier */
 735         if (pneg_rsp->Dialect !=
 736                         cpu_to_le16(tcon->ses->server->vals->protocol_id))
 737                 goto vneg_out;

My main question here is whether this bug has security implications - if I understand the purpose of validate negotiate info correctly, it's normally issued by the client immediately following SMB2 Negotiate, to ensure that dialect negotiation wasn't downgraded by a MITM attacker. That would mean that the session is authenticated, and that packet signing would already be active,
in which case I don't think it's worth a CVE here. What do others think?

Patches to follow...