Subject: CVE-2024-41050: cachefiles: cyclic allocation of msg_id to avoid reuse

From: Greg Kroah-Hartman <[email-masked]>

Description
===========

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
-------------------------------------------------
cachefiles_ondemand_select_req
 cachefiles_ondemand_object_is_close(A)
 cachefiles_ondemand_set_object_reopening(A)
 queue_work(fscache_object_wq, &info->work)
                ondemand_object_worker
                 cachefiles_ondemand_init_object(A)
                  cachefiles_ondemand_send_req(OPEN)
                    // get msg_id 6
                    wait_for_completion(&req_A->done)
cachefiles_ondemand_daemon_read
 // read msg_id 6 req_A
 cachefiles_ondemand_get_fd
 copy_to_user
                                // Malicious completion msg_id 6
                                copen 6,-1
                                cachefiles_ondemand_copen
                                 complete(&req_A->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
process_open_req
 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 msg_id cyclically to avoid reusing the
msg_id for a very short duration of time.

The Linux kernel CVE team has assigned CVE-2024-41050 to this issue.

Affected and fixed versions
===========================

	Issue introduced in 5.19 with commit c8383054506c and fixed in 6.1.100 with commit 35710c6c4a1c
	Issue introduced in 5.19 with commit c8383054506c and fixed in 6.6.41 with commit de045a82e1a4
	Issue introduced in 5.19 with commit c8383054506c and fixed in 6.9.10 with commit 9d3bf4e9aa23
	Issue introduced in 5.19 with commit c8383054506c and fixed in 6.10 with commit 19f4f3990914

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2024-41050
will be updated if fixes are backported, please check that for the most
up to date information about this issue.

Affected files
==============

The file(s) affected by this issue are:
	fs/cachefiles/internal.h
	fs/cachefiles/ondemand.c

Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/35710c6c4a1c64478ec1b5e0e81d386c0844dec6
	https://git.kernel.org/stable/c/de045a82e1a4e04be62718d3c2981a55150765a0
	https://git.kernel.org/stable/c/9d3bf4e9aa23f0d9e99ebe7a94f232ddba54ee17
	https://git.kernel.org/stable/c/19f4f399091478c95947f6bd7ad61622300c30d9