In the Linux kernel, the following vulnerability has been resolved: cachefiles: cyclic allocation of msgid to avoid reuse Reusing the msgid after a maliciously completed reopen request may cause a read request to remain unprocessed and result in a hung, as shown below: t1 | t2 | t3 ------------------------------------------------- cachefilesondemandselectreq cachefilesondemandobjectisclose(A) cachefilesondemandsetobjectreopening(A) queuework(fscacheobjectwq, &info->work) ondemandobjectworker cachefilesondemandinitobject(A) cachefilesondemandsendreq(OPEN) // get msgid 6 waitforcompletion(&reqA->done) cachefilesondemanddaemonread // read msgid 6 reqA cachefilesondemandgetfd copytouser // Malicious completion msgid 6 copen 6,-1 cachefilesondemandcopen complete(&reqA->done) // will not set the object to close // because ondemandid && fd is valid. // ondemandobjectworker() is done // but the object is still reopening. // new open reqB cachefilesondemandinitobject(B) cachefilesondemandsendreq(OPEN) // reuse msgid 6 processopenreq copen 6,A.size // The expected failed copen was executed successfully Expect copen to fail, and when it does, it closes fd, which sets the object to close, and then close triggers reopen again. However, due to msgid reuse resulting in a successful copen, the anonymous fd is not closed until the daemon exits. Therefore read requests waiting for reopen to complete may trigger hung task. To avoid this issue, allocate the msgid cyclically to avoid reusing the msgid for a very short duration of time.