CVSS: -EPSS: %CPEs: 9EXPL: 0CVE-2024-53157 – firmware: arm_scpi: Check the DVFS OPP count returned by the firmware
https://notcve.org/view.php?id=CVE-2024-53157
In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scpi: Check the DVFS OPP count returned by the firmware Fix a kernel crash with the below call trace when the SCPI firmware returns OPP count of zero. dvfs_info.opp_count may be zero on some platforms during the reboot test, and the kernel will crash after dereferencing the pointer to kcalloc(info->count, sizeof(*opp), GFP_KERNEL). | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028 | Mem abort info: | ESR = 0x96000004 | Exception class = DABT (current EL), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | Data abort info: | ISV = 0, ISS = 0x00000004 | CM = 0, WnR = 0 | user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000faefa08c | [0000000000000028] pgd=0000000000000000 | Internal error: Oops: 96000004 [#1] SMP | scpi-hwmon: probe of PHYT000D:00 failed with error -110 | Process systemd-udevd (pid: 1701, stack limit = 0x00000000aaede86c) | CPU: 2 PID: 1701 Comm: systemd-udevd Not tainted 4.19.90+ #1 | Hardware name: PHYTIUM LTD Phytium FT2000/4/Phytium FT2000/4, BIOS | pstate: 60000005 (nZCv daif -PAN -UAO) | pc : scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi] | lr : clk_register+0x438/0x720 | Call trace: | scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi] | devm_clk_hw_register+0x50/0xa0 | scpi_clk_ops_init.isra.2+0xa0/0x138 [clk_scpi] | scpi_clocks_probe+0x528/0x70c [clk_scpi] | platform_drv_probe+0x58/0xa8 | really_probe+0x260/0x3d0 | driver_probe_device+0x12c/0x148 | device_driver_attach+0x74/0x98 | __driver_attach+0xb4/0xe8 | bus_for_each_dev+0x88/0xe0 | driver_attach+0x30/0x40 | bus_add_driver+0x178/0x2b0 | driver_register+0x64/0x118 | __platform_driver_register+0x54/0x60 | scpi_clocks_driver_init+0x24/0x1000 [clk_scpi] | do_one_initcall+0x54/0x220 | do_init_module+0x54/0x1c8 | load_module+0x14a4/0x1668 | __se_sys_finit_module+0xf8/0x110 | __arm64_sys_finit_module+0x24/0x30 | el0_svc_common+0x78/0x170 | el0_svc_handler+0x38/0x78 | el0_svc+0x8/0x340 | Code: 937d7c00 a94153f3 a8c27bfd f9400421 (b8606820) | ---[ end trace 06feb22469d89fa8 ]--- | Kernel panic - not syncing: Fatal exception | SMP: stopping secondary CPUs | Kernel Offset: disabled | CPU features: 0x10,a0002008 | Memory Limit: none • https://git.kernel.org/stable/c/8cb7cf56c9fe5412de238465b27ef35b4d2801aa https://git.kernel.org/stable/c/12e2c520a0a4202575e4a45ea41f06a8e9aa3417 https://git.kernel.org/stable/c/8be4e51f3ecfb0915e3510b600c4cce0dc68a383 https://git.kernel.org/stable/c/380c0e1d96f3b522f3170c18ee5e0f1a28fec5d6 https://git.kernel.org/stable/c/2a5b8de6fcb944f9af0c5fcb30bb0c039705e051 https://git.kernel.org/stable/c/06258e57fee253f4046d3a6a86d7fde09f596eac https://git.kernel.org/stable/c/025067eeb945aa17c7dd483a63960125b7efb577 https://git.kernel.org/stable/c/dfc9c2aa7f04f7db7e7225a5e118a24bf •
CVSS: -EPSS: %CPEs: 9EXPL: 0CVE-2024-53156 – wifi: ath9k: add range check for conn_rsp_epid in htc_connect_service()
https://notcve.org/view.php?id=CVE-2024-53156
In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: add range check for conn_rsp_epid in htc_connect_service() I found the following bug in my fuzzer: UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath9k/htc_hst.c:26:51 index 255 is out of range for type 'htc_endpoint [22]' CPU: 0 UID: 0 PID: 8 Comm: kworker/0:0 Not tainted 6.11.0-rc6-dirty #14 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: events request_firmware_work_func Call Trace: <TASK> dump_stack_lvl+0x180/0x1b0 __ubsan_handle_out_of_bounds+0xd4/0x130 htc_issue_send.constprop.0+0x20c/0x230 ? _raw_spin_unlock_irqrestore+0x3c/0x70 ath9k_wmi_cmd+0x41d/0x610 ? mark_held_locks+0x9f/0xe0 ... Since this bug has been confirmed to be caused by insufficient verification of conn_rsp_epid, I think it would be appropriate to add a range check for conn_rsp_epid to htc_connect_service() to prevent the bug from occurring. • https://git.kernel.org/stable/c/fb9987d0f748c983bb795a86f47522313f701a08 https://git.kernel.org/stable/c/5f177fb9d01355ac183e65ad8909ea8ef734e0cf https://git.kernel.org/stable/c/cb480ae80fd4d0f1ac9e107ce799183beee5124b https://git.kernel.org/stable/c/c941af142200d975dd3be632aeb490f4cb91dae4 https://git.kernel.org/stable/c/8965db7fe2e913ee0802b05fc94c6d6aa74e0596 https://git.kernel.org/stable/c/70eae50d2156cb6e078d0d78809b49bf2f4c7540 https://git.kernel.org/stable/c/b6551479daf2bfa80bfd5d9016b02a810e508bfb https://git.kernel.org/stable/c/3fe99b9690b99606d3743c9961ebee865 •
CVSS: -EPSS: %CPEs: 9EXPL: 0CVE-2024-53155 – ocfs2: fix uninitialized value in ocfs2_file_read_iter()
https://notcve.org/view.php?id=CVE-2024-53155
In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix uninitialized value in ocfs2_file_read_iter() Syzbot has reported the following KMSAN splat: BUG: KMSAN: uninit-value in ocfs2_file_read_iter+0x9a4/0xf80 ocfs2_file_read_iter+0x9a4/0xf80 __io_read+0x8d4/0x20f0 io_read+0x3e/0xf0 io_issue_sqe+0x42b/0x22c0 io_wq_submit_work+0xaf9/0xdc0 io_worker_handle_work+0xd13/0x2110 io_wq_worker+0x447/0x1410 ret_from_fork+0x6f/0x90 ret_from_fork_asm+0x1a/0x30 Uninit was created at: __alloc_pages_noprof+0x9a7/0xe00 alloc_pages_mpol_noprof+0x299/0x990 alloc_pages_noprof+0x1bf/0x1e0 allocate_slab+0x33a/0x1250 ___slab_alloc+0x12ef/0x35e0 kmem_cache_alloc_bulk_noprof+0x486/0x1330 __io_alloc_req_refill+0x84/0x560 io_submit_sqes+0x172f/0x2f30 __se_sys_io_uring_enter+0x406/0x41c0 __x64_sys_io_uring_enter+0x11f/0x1a0 x64_sys_call+0x2b54/0x3ba0 do_syscall_64+0xcd/0x1e0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Since an instance of 'struct kiocb' may be passed from the block layer with 'private' field uninitialized, introduce 'ocfs2_iocb_init_rw_locked()' and use it from where 'ocfs2_dio_end_io()' might take care, i.e. in 'ocfs2_file_read_iter()' and 'ocfs2_file_write_iter()'. • https://git.kernel.org/stable/c/7cdfc3a1c3971c9125c317cb8c2525745851798e https://git.kernel.org/stable/c/6c8f8d1e595dabd5389817f6d798cc8bd95c40ab https://git.kernel.org/stable/c/f4078ef38d3163e6be47403a619558b19c4bfccd https://git.kernel.org/stable/c/66b7ddd1804e2c4216dd7ead8eeb746cdbb3b62f https://git.kernel.org/stable/c/8c966150d5abff58c3c2bdb9a6e63fd773782905 https://git.kernel.org/stable/c/83f8713a0ef1d55d6a287bcfadcaab8245ac5098 https://git.kernel.org/stable/c/8e0de82ed18ba0e71f817adbd81317fd1032ca5a https://git.kernel.org/stable/c/366c933c2ab34dd6551acc03b4872726b •
CVSS: -EPSS: %CPEs: 8EXPL: 0CVE-2024-53150 – ALSA: usb-audio: Fix out of bounds reads when finding clock sources
https://notcve.org/view.php?id=CVE-2024-53150
In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix out of bounds reads when finding clock sources The current USB-audio driver code doesn't check bLength of each descriptor at traversing for clock descriptors. That is, when a device provides a bogus descriptor with a shorter bLength, the driver might hit out-of-bounds reads. For addressing it, this patch adds sanity checks to the validator functions for the clock descriptor traversal. When the descriptor length is shorter than expected, it's skipped in the loop. For the clock source and clock multiplier descriptors, we can just check bLength against the sizeof() of each descriptor type. OTOH, the clock selector descriptor of UAC2 and UAC3 has an array of bNrInPins elements and two more fields at its tail, hence those have to be checked in addition to the sizeof() check. • https://git.kernel.org/stable/c/a632bdcb359fd8145e86486ff8612da98e239acd https://git.kernel.org/stable/c/45a92cbc88e4013bfed7fd2ccab3ade45f8e896b https://git.kernel.org/stable/c/ab011f7439d9bbfd34fd3b9cef4b2d6d952c9bb9 https://git.kernel.org/stable/c/da13ade87a12dd58829278bc816a61bea06a56a9 https://git.kernel.org/stable/c/74cb86e1006c5437b1d90084d22018da30fddc77 https://git.kernel.org/stable/c/ea0fa76f61cf8e932d1d26e6193513230816e11d https://git.kernel.org/stable/c/096bb5b43edf755bc4477e64004fa3a20539ec2f https://git.kernel.org/stable/c/a3dd4d63eeb452cfb064a13862fb376ab •
CVSS: -EPSS: %CPEs: 8EXPL: 0CVE-2024-53148 – comedi: Flush partial mappings in error case
https://notcve.org/view.php?id=CVE-2024-53148
In the Linux kernel, the following vulnerability has been resolved: comedi: Flush partial mappings in error case If some remap_pfn_range() calls succeeded before one failed, we still have buffer pages mapped into the userspace page tables when we drop the buffer reference with comedi_buf_map_put(bm). The userspace mappings are only cleaned up later in the mmap error path. Fix it by explicitly flushing all mappings in our VMA on the error path. See commit 79a61cc3fc04 ("mm: avoid leaving partial pfn mappings around in error case"). • https://git.kernel.org/stable/c/ed9eccbe8970f6eedc1b978c157caf1251a896d4 https://git.kernel.org/stable/c/57f048c2d205b85e34282a9b0b0ae177e84c2f44 https://git.kernel.org/stable/c/b9322408d83accc8b96322bc7356593206288c56 https://git.kernel.org/stable/c/8797b7712de704dc231f9e821d8eb3b9aeb3a032 https://git.kernel.org/stable/c/16c507df509113c037cdc0ba642b9ab3389bd26c https://git.kernel.org/stable/c/9b07fb464eb69a752406e78e62ab3a60bfa7b00d https://git.kernel.org/stable/c/c6963a06ce5c61d3238751ada04ee1569663a828 https://git.kernel.org/stable/c/297f14fbb81895f4ccdb0ad25d196786d •