| From bippy-5f407fcff5a0 Mon Sep 17 00:00:00 2001 |
| From: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
| To: <linux-cve-announce@vger.kernel.org> |
| Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org> |
| Subject: CVE-2024-41051: cachefiles: wait for ondemand_object_worker to finish when dropping object |
| |
| Description |
| =========== |
| |
| In the Linux kernel, the following vulnerability has been resolved: |
| |
| cachefiles: wait for ondemand_object_worker to finish when dropping object |
| |
| When queuing ondemand_object_worker() to re-open the object, |
| cachefiles_object is not pinned. The cachefiles_object may be freed when |
| the pending read request is completed intentionally and the related |
| erofs is umounted. If ondemand_object_worker() runs after the object is |
| freed, it will incur use-after-free problem as shown below. |
| |
| process A processs B process C process D |
| |
| cachefiles_ondemand_send_req() |
| // send a read req X |
| // wait for its completion |
| |
| // close ondemand fd |
| cachefiles_ondemand_fd_release() |
| // set object as CLOSE |
| |
| cachefiles_ondemand_daemon_read() |
| // set object as REOPENING |
| queue_work(fscache_wq, &info->ondemand_work) |
| |
| // close /dev/cachefiles |
| cachefiles_daemon_release |
| cachefiles_flush_reqs |
| complete(&req->done) |
| |
| // read req X is completed |
| // umount the erofs fs |
| cachefiles_put_object() |
| // object will be freed |
| cachefiles_ondemand_deinit_obj_info() |
| kmem_cache_free(object) |
| // both info and object are freed |
| ondemand_object_worker() |
| |
| When dropping an object, it is no longer necessary to reopen the object, |
| so use cancel_work_sync() to cancel or wait for ondemand_object_worker() |
| to finish. |
| |
| The Linux kernel CVE team has assigned CVE-2024-41051 to this issue. |
| |
| |
| Affected and fixed versions |
| =========================== |
| |
| Issue introduced in 6.1.95 with commit f17443d52d805c9a7fab5e67a4e8b973626fe1cd and fixed in 6.1.100 with commit ec9289369259d982e735a71437e32e6b4035290c |
| Issue introduced in 6.6.35 with commit f740fd943bb1fbf79b7eaba3c71eb7536f437f51 and fixed in 6.6.41 with commit d3179bae72b1b5e555ba839d6d9f40a350a4d78a |
| Issue introduced in 6.8 with commit 0a7e54c1959c0feb2de23397ec09c7692364313e and fixed in 6.9.10 with commit b26525b2183632f16a3a4108fe6a4bfa8afac6ed |
| Issue introduced in 6.8 with commit 0a7e54c1959c0feb2de23397ec09c7692364313e and fixed in 6.10 with commit 12e009d60852f7bce0afc373ca0b320f14150418 |
| |
| 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-41051 |
| 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/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/ec9289369259d982e735a71437e32e6b4035290c |
| https://git.kernel.org/stable/c/d3179bae72b1b5e555ba839d6d9f40a350a4d78a |
| https://git.kernel.org/stable/c/b26525b2183632f16a3a4108fe6a4bfa8afac6ed |
| https://git.kernel.org/stable/c/12e009d60852f7bce0afc373ca0b320f14150418 |
