CVE-2024-41050

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

cachefiles: cyclic allocation of msg_id to avoid reuse

Reusing the msg_id 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 ondemand_id && fd is valid.

            // ondemand_object_worker() is done
            // but the object is still reopening.

                            // new open req_B
                            cachefiles_ondemand_init_object(B)
                             cachefiles_ondemand_send_req(OPEN)
                             // reuse msg_id 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 msg_id 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.