linux-kernel - Re: [PATCH] CIFS: Prevent error log on spurious oplock break

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <871rcpx2e4.fsf@suse.com>
Date:   Mon, 08 Mar 2021 13:20:51 +0100
From:   Aurélien Aptel <aaptel@...e.com>
To:     Shyam Prasad N <nspmangalore@...il.com>,
        Vincent Whitchurch <vincent.whitchurch@...s.com>
Cc:     Pavel Shilovsky <pshilov@...rosoft.com>,
        Steve French <sfrench@...ba.org>, kernel@...s.com,
        CIFS <linux-cifs@...r.kernel.org>,
        samba-technical <samba-technical@...ts.samba.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] CIFS: Prevent error log on spurious oplock break

Shyam Prasad N <nspmangalore@...il.com> writes:
> So I don't think we should be changing the logic here.

I would tend to agree.

> If SMB v1 had a different behaviour, we should check if that is as per
> the protocol documentation. If not, change it.

I think the main difference is that SMBv1 doesn't have the concept of
lease keys. I think lease keys were added to handle cases like this:

case a)

client: >> send create+lease (key=XYZ). I don't know the file fid yet

server: local open & concurent open (create response not sent yet!)

server: << send oplockbreak key=XYZ
client: dont know the fid, but i can match the lease key with a request
        I made, so it's valid

server: << send create response (fid=123)
client: I know the fid now

case b)

client: >> send create+lease (key=XYZ)
server: << open file, send create response (fid=123)

client: >> close file, release file ressources, send close fid=123
server: before receiving close, concurrent open happens
server: << send oplock break (key=XYZ)
server: << send close
client: depending on the order the response are processed, I might not
        process oplock because i don't know this file! I already closed
        it. But I know this lease key

Without client-generated lease keys you cannot match things you don't
have an FID for (because you haven't received it yet, or because it was
closed). And FIDs can be reused and point to different files.

Cheers,
-- 
Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München)