CVE-2022-49296: ceph: fix possible deadlock when holding Fwb to get inline_data

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

ceph: fix possible deadlock when holding Fwb to get inlinedata

1, mount with wsync. 2, create a file with ORDWR, and the request was sent to mds.0:

cephatomicopen()--> cephmdscdorequest(openc) finishopen(file, dentry, cephopen)--> cephopen()--> cephinitfile()--> cephinitfileinfo()--> cephuninlinedata()--> { ... if (inlineversion == 1 || / initial version, no data / inlineversion == CEPHINLINENONE) goto outunlock; ... }

The inlineversion will be 1, which is the initial version for the new create file. And here the ci->iinlineversion will keep with 1, it's buggy.

3, buffer write to the file immediately:

cephwriteiter()--> cephgetcaps(file, need=Fw, want=Fb, ...); genericperformwrite()--> aops->writebegin()--> cephwritebegin()--> netfswritebegin()--> netfsbeginread()--> netfsrreqsubmitslice()--> netfsreadfromserver()--> rreq->netfsops->issueread()--> cephnetfsissueread()--> { ... if (ci->iinlineversion != CEPHINLINENONE && cephnetfsissueopinline(subreq)) return; ... } cephputcaprefs(ci, Fwb);

The cephnetfsissueopinline() will send a getattr(Fsr) request to mds.1.

4, then the mds.1 will request the rd lock for CInode::filelock from the auth mds.0, the mds.0 will do the CInode::filelock state transation from excl --> sync, but it need to revoke the Fxwb caps back from the clients.

While the kernel client has aleady held the Fwb caps and waiting for the getattr(Fsr).

It's deadlock!

URL: https://tracker.ceph.com/issues/55377