CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-46694 – drm/amd/display: avoid using null object of framebuffer
https://notcve.org/view.php?id=CVE-2024-46694
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: avoid using null object of framebuffer Instead of using state->fb->obj[0] directly, get object from framebuffer by calling drm_gem_fb_get_obj() and return error code when object is null to avoid using null object of framebuffer. (cherry picked from commit 73dd0ad9e5dad53766ea3e631303430116f834b3) • https://git.kernel.org/stable/c/5d945cbcd4b16a29d6470a80dfb19738f9a4319f https://git.kernel.org/stable/c/c46dda486e4f9b86eeac40aaea65a6f93dc44dad https://git.kernel.org/stable/c/093ee72ed35c2338c87c26b6ba6f0b7789c9e14e https://git.kernel.org/stable/c/f6f5e39a3fe7cbdba190f42b28b40bdff03c8cf0 https://git.kernel.org/stable/c/49e1b214f3239b78967c6ddb8f8ec47ae047b051 https://git.kernel.org/stable/c/3b9a33235c773c7a3768060cf1d2cf8a9153bc37 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-46693 – soc: qcom: pmic_glink: Fix race during initialization
https://notcve.org/view.php?id=CVE-2024-46693
In the Linux kernel, the following vulnerability has been resolved: soc: qcom: pmic_glink: Fix race during initialization As pointed out by Stephen Boyd it is possible that during initialization of the pmic_glink child drivers, the protection-domain notifiers fires, and the associated work is scheduled, before the client registration returns and as a result the local "client" pointer has been initialized. The outcome of this is a NULL pointer dereference as the "client" pointer is blindly dereferenced. Timeline provided by Stephen: CPU0 CPU1 ---- ---- ucsi->client = NULL; devm_pmic_glink_register_client() client->pdr_notify(client->priv, pg->client_state) pmic_glink_ucsi_pdr_notify() schedule_work(&ucsi->register_work) <schedule away> pmic_glink_ucsi_register() ucsi_register() pmic_glink_ucsi_read_version() pmic_glink_ucsi_read() pmic_glink_ucsi_read() pmic_glink_send(ucsi->client) <client is NULL BAD> ucsi->client = client // Too late! This code is identical across the altmode, battery manager and usci child drivers. Resolve this by splitting the allocation of the "client" object and the registration thereof into two operations. This only happens if the protection domain registry is populated at the time of registration, which by the introduction of commit '1ebcde047c54 ("soc: qcom: add pd-mapper implementation")' became much more likely. • https://git.kernel.org/stable/c/58ef4ece1e41ac525db3e79529909683325d85df https://git.kernel.org/stable/c/1efdbf5323c9360e05066049b97414405e94e087 https://git.kernel.org/stable/c/943b0e7cc646a624bb20a68080f8f1a4a55df41c https://git.kernel.org/stable/c/3568affcddd68743e25aa3ec1647d9b82797757b •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-46692 – firmware: qcom: scm: Mark get_wq_ctx() as atomic call
https://notcve.org/view.php?id=CVE-2024-46692
In the Linux kernel, the following vulnerability has been resolved: firmware: qcom: scm: Mark get_wq_ctx() as atomic call Currently get_wq_ctx() is wrongly configured as a standard call. When two SMC calls are in sleep and one SMC wakes up, it calls get_wq_ctx() to resume the corresponding sleeping thread. But if get_wq_ctx() is interrupted, goes to sleep and another SMC call is waiting to be allocated a waitq context, it leads to a deadlock. To avoid this get_wq_ctx() must be an atomic call and can't be a standard SMC call. Hence mark get_wq_ctx() as a fast call. • https://git.kernel.org/stable/c/6bf32599223634294cdc6efb359ffaab1d68073c https://git.kernel.org/stable/c/cdf7efe4b02aa93813db0bf1ca596ad298ab6b06 https://git.kernel.org/stable/c/e40115c33c0d79c940545b6b12112aace7acd9f5 https://git.kernel.org/stable/c/9960085a3a82c58d3323c1c20b991db6045063b0 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-46689 – soc: qcom: cmd-db: Map shared memory as WC, not WB
https://notcve.org/view.php?id=CVE-2024-46689
In the Linux kernel, the following vulnerability has been resolved: soc: qcom: cmd-db: Map shared memory as WC, not WB Linux does not write into cmd-db region. This region of memory is write protected by XPU. XPU may sometime falsely detect clean cache eviction as "write" into the write protected region leading to secure interrupt which causes an endless loop somewhere in Trust Zone. The only reason it is working right now is because Qualcomm Hypervisor maps the same region as Non-Cacheable memory in Stage 2 translation tables. The issue manifests if we want to use another hypervisor (like Xen or KVM), which does not know anything about those specific mappings. Changing the mapping of cmd-db memory from MEMREMAP_WB to MEMREMAP_WT/WC removes dependency on correct mappings in Stage 2 tables. This patch fixes the issue by updating the mapping to MEMREMAP_WC. I tested this on SA8155P with Xen. • https://git.kernel.org/stable/c/312416d9171a1460b7ed8d182b5b540c910ce80d https://git.kernel.org/stable/c/0ee9594c974368a17e85a431e9fe1c14fb65c278 https://git.kernel.org/stable/c/f5a5a5a0e95f36e2792d48e6e4b64e665eb01374 https://git.kernel.org/stable/c/eaff392c1e34fb77cc61505a31b0191e5e46e271 https://git.kernel.org/stable/c/d9d48d70e922b272875cda60d2ada89291c840cf https://git.kernel.org/stable/c/ef80520be0ff78ae5ed44cb6eee1525e65bebe70 https://git.kernel.org/stable/c/62c2d63605ca25b5db78a347ed303c0a0a77d5b4 https://git.kernel.org/stable/c/f9bb896eab221618927ae6a2f1d566567 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-46687 – btrfs: fix a use-after-free when hitting errors inside btrfs_submit_chunk()
https://notcve.org/view.php?id=CVE-2024-46687
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix a use-after-free when hitting errors inside btrfs_submit_chunk() [BUG] There is an internal report that KASAN is reporting use-after-free, with the following backtrace: BUG: KASAN: slab-use-after-free in btrfs_check_read_bio+0xa68/0xb70 [btrfs] Read of size 4 at addr ffff8881117cec28 by task kworker/u16:2/45 CPU: 1 UID: 0 PID: 45 Comm: kworker/u16:2 Not tainted 6.11.0-rc2-next-20240805-default+ #76 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 Workqueue: btrfs-endio btrfs_end_bio_work [btrfs] Call Trace: dump_stack_lvl+0x61/0x80 print_address_description.constprop.0+0x5e/0x2f0 print_report+0x118/0x216 kasan_report+0x11d/0x1f0 btrfs_check_read_bio+0xa68/0xb70 [btrfs] process_one_work+0xce0/0x12a0 worker_thread+0x717/0x1250 kthread+0x2e3/0x3c0 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x11/0x20 Allocated by task 20917: kasan_save_stack+0x37/0x60 kasan_save_track+0x10/0x30 __kasan_slab_alloc+0x7d/0x80 kmem_cache_alloc_noprof+0x16e/0x3e0 mempool_alloc_noprof+0x12e/0x310 bio_alloc_bioset+0x3f0/0x7a0 btrfs_bio_alloc+0x2e/0x50 [btrfs] submit_extent_page+0x4d1/0xdb0 [btrfs] btrfs_do_readpage+0x8b4/0x12a0 [btrfs] btrfs_readahead+0x29a/0x430 [btrfs] read_pages+0x1a7/0xc60 page_cache_ra_unbounded+0x2ad/0x560 filemap_get_pages+0x629/0xa20 filemap_read+0x335/0xbf0 vfs_read+0x790/0xcb0 ksys_read+0xfd/0x1d0 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Freed by task 20917: kasan_save_stack+0x37/0x60 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x50 __kasan_slab_free+0x4b/0x60 kmem_cache_free+0x214/0x5d0 bio_free+0xed/0x180 end_bbio_data_read+0x1cc/0x580 [btrfs] btrfs_submit_chunk+0x98d/0x1880 [btrfs] btrfs_submit_bio+0x33/0x70 [btrfs] submit_one_bio+0xd4/0x130 [btrfs] submit_extent_page+0x3ea/0xdb0 [btrfs] btrfs_do_readpage+0x8b4/0x12a0 [btrfs] btrfs_readahead+0x29a/0x430 [btrfs] read_pages+0x1a7/0xc60 page_cache_ra_unbounded+0x2ad/0x560 filemap_get_pages+0x629/0xa20 filemap_read+0x335/0xbf0 vfs_read+0x790/0xcb0 ksys_read+0xfd/0x1d0 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [CAUSE] Although I cannot reproduce the error, the report itself is good enough to pin down the cause. The call trace is the regular endio workqueue context, but the free-by-task trace is showing that during btrfs_submit_chunk() we already hit a critical error, and is calling btrfs_bio_end_io() to error out. And the original endio function called bio_put() to free the whole bio. This means a double freeing thus causing use-after-free, e.g.: 1. Enter btrfs_submit_bio() with a read bio The read bio length is 128K, crossing two 64K stripes. 2. The first run of btrfs_submit_chunk() 2.1 Call btrfs_map_block(), which returns 64K 2.2 Call btrfs_split_bio() Now there are two bios, one referring to the first 64K, the other referring to the second 64K. 2.3 The first half is submitted. 3. • https://git.kernel.org/stable/c/852eee62d31abd695cd43e1b875d664ed292a8ca https://git.kernel.org/stable/c/51722b99f41f5e722ffa10b8f61e802a0e70b331 https://git.kernel.org/stable/c/4a3b9e1a8e6cd1a8d427a905e159de58d38941cc https://git.kernel.org/stable/c/10d9d8c3512f16cad47b2ff81ec6fc4b27d8ee10 •