Hi Stefano, Good catch! But I think this bug hides a bigger more sinister bug... Stefano Brivio <sbrivio@xxxxxxxxxx> writes: > - buf->lcontext.LeaseKeyLow = cpu_to_le64(*((u64 *)lease_key)); > - buf->lcontext.LeaseKeyHigh = cpu_to_le64(*((u64 *)(lease_key + 8))); > + get_random_bytes(&buf->lcontext.LeaseKey, SMB2_LEASE_KEY_SIZE); > buf->lcontext.LeaseState = map_oplock_to_lease(oplock); I know the value used to be kind of random and changing it to actual random bytes should be the same however we already have a function to generate a lease key in the generic version operations: /* generate new lease key */ void (*new_lease_key)(struct cifs_fid *); Which are used to set the lease key in a struct cifs_fid and are called on both create & open code paths (in cifs_create and cifs_atomic_open). I think the code is assuming being called by smb2_open_file(): __u8 smb2_oplock[17]; <--- space for oplock type + key buffer ... *smb2_oplock = SMB2_OPLOCK_LEVEL_BATCH; ... if (oparms->tcon->ses->server->capabilities & SMB2_GLOBAL_CAP_LEASING) memcpy(smb2_oplock + 1, fid->lease_key, SMB2_LEASE_KEY_SIZE); ... rc = SMB2_open(xid, oparms, smb2_path, smb2_oplock, smb2_data, NULL, NULL); So it seems all SMB2_open() callers that request an oplock MUST allocate this 17 bytes buffer and from a quick look many of them don't. The proper fix would be to pass the fid->lease_key when creating the context. Hope that was helpful enough for a v2 ;) Cheers, -- Aurélien Aptel / SUSE Labs Samba Team GPG: 1839 CB5F 9F5B FB9B AA97 8C99 03C8 A49B 521B D5D3 SUSE Linux GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
