CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-56621 – scsi: ufs: core: Cancel RTC work during ufshcd_remove()
https://notcve.org/view.php?id=CVE-2024-56621
In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Cancel RTC work during ufshcd_remove() Currently, RTC work is only cancelled during __ufshcd_wl_suspend(). When ufshcd is removed in ufshcd_remove(), RTC work is not cancelled. Due to this, any further trigger of the RTC work after ufshcd_remove() would result in a NULL pointer dereference as below: Unable to handle kernel NULL pointer dereference at virtual address 00000000000002a4 Workqueue: events ufshcd_rtc_work Call trace: _raw_spin_lock_irqsave+0x34/0x8c pm_runtime_get_if_active+0x24/0xb4 ufshcd_rtc_work+0x124/0x19c process_scheduled_works+0x18c/0x2d8 worker_thread+0x144/0x280 kthread+0x11c/0x128 ret_from_fork+0x10/0x20 Since RTC work accesses the ufshcd internal structures, it should be cancelled when ufshcd is removed. So do that in ufshcd_remove(), as per the order in ufshcd_init(). • https://git.kernel.org/stable/c/6bf999e0eb41850d5c857102535d5c53b2ede224 https://git.kernel.org/stable/c/2e7a3bb0331efb292e0fb022c36bc592137f0520 https://git.kernel.org/stable/c/1695c4361d35b7bdadd7b34f99c9c07741e181e5 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-56620 – scsi: ufs: qcom: Only free platform MSIs when ESI is enabled
https://notcve.org/view.php?id=CVE-2024-56620
In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: qcom: Only free platform MSIs when ESI is enabled Otherwise, it will result in a NULL pointer dereference as below: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 Call trace: mutex_lock+0xc/0x54 platform_device_msi_free_irqs_all+0x14/0x20 ufs_qcom_remove+0x34/0x48 [ufs_qcom] platform_remove+0x28/0x44 device_remove+0x4c/0x80 device_release_driver_internal+0xd8/0x178 driver_detach+0x50/0x9c bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 platform_driver_unregister+0x14/0x20 ufs_qcom_pltform_exit+0x18/0xb94 [ufs_qcom] __arm64_sys_delete_module+0x180/0x260 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xdc el0t_64_sync_handler+0xc0/0xc4 el0t_64_sync+0x190/0x194 • https://git.kernel.org/stable/c/519b6274a7775f5fe00a086f189efb8f063467d1 https://git.kernel.org/stable/c/f99cb5f6344ef93777fd3add7979ebf291a852df https://git.kernel.org/stable/c/64506b3d23a337e98a74b18dcb10c8619365f2bd •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-56619 – nilfs2: fix potential out-of-bounds memory access in nilfs_find_entry()
https://notcve.org/view.php?id=CVE-2024-56619
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential out-of-bounds memory access in nilfs_find_entry() Syzbot reported that when searching for records in a directory where the inode's i_size is corrupted and has a large value, memory access outside the folio/page range may occur, or a use-after-free bug may be detected if KASAN is enabled. This is because nilfs_last_byte(), which is called by nilfs_find_entry() and others to calculate the number of valid bytes of directory data in a page from i_size and the page index, loses the upper 32 bits of the 64-bit size information due to an inappropriate type of local variable to which the i_size value is assigned. This caused a large byte offset value due to underflow in the end address calculation in the calling nilfs_find_entry(), resulting in memory access that exceeds the folio/page size. Fix this issue by changing the type of the local variable causing the bit loss from "unsigned int" to "u64". The return value of nilfs_last_byte() is also of type "unsigned int", but it is truncated so as not to exceed PAGE_SIZE and no bit loss occurs, so no change is required. • https://git.kernel.org/stable/c/2ba466d74ed74f073257f86e61519cb8f8f46184 https://git.kernel.org/stable/c/09d6d05579fd46e61abf6e457bb100ff11f3a9d3 https://git.kernel.org/stable/c/e3732102a9d638d8627d14fdf7b208462f0520e0 https://git.kernel.org/stable/c/48eb6e7404948032bbe811c5affbe39f6b316951 https://git.kernel.org/stable/c/5af8366625182f01f6d8465c9a3210574673af57 https://git.kernel.org/stable/c/c3afea07477baccdbdec4483f8d5e59d42a3f67f https://git.kernel.org/stable/c/31f7b57a77d4c82a34ddcb6ff35b5aa577ef153e https://git.kernel.org/stable/c/985ebec4ab0a28bb5910c3b1481a40fbf •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-56617 – cacheinfo: Allocate memory during CPU hotplug if not done from the primary CPU
https://notcve.org/view.php?id=CVE-2024-56617
In the Linux kernel, the following vulnerability has been resolved: cacheinfo: Allocate memory during CPU hotplug if not done from the primary CPU Commit 5944ce092b97 ("arch_topology: Build cacheinfo from primary CPU") adds functionality that architectures can use to optionally allocate and build cacheinfo early during boot. Commit 6539cffa9495 ("cacheinfo: Add arch specific early level initializer") lets secondary CPUs correct (and reallocate memory) cacheinfo data if needed. If the early build functionality is not used and cacheinfo does not need correction, memory for cacheinfo is never allocated. x86 does not use the early build functionality. Consequently, during the cacheinfo CPU hotplug callback, last_level_cache_is_valid() attempts to dereference a NULL pointer: BUG: kernel NULL pointer dereference, address: 0000000000000100 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not present page PGD 0 P4D 0 Oops: 0000 [#1] PREEPMT SMP NOPTI CPU: 0 PID 19 Comm: cpuhp/0 Not tainted 6.4.0-rc2 #1 RIP: 0010: last_level_cache_is_valid+0x95/0xe0a Allocate memory for cacheinfo during the cacheinfo CPU hotplug callback if not done earlier. Moreover, before determining the validity of the last-level cache info, ensure that it has been allocated. Simply checking for non-zero cache_leaves() is not sufficient, as some architectures (e.g., Intel processors) have non-zero cache_leaves() before allocation. Dereferencing NULL cacheinfo can occur in update_per_cpu_data_slice_size(). This function iterates over all online CPUs. However, a CPU may have come online recently, but its cacheinfo may not have been allocated yet. While here, remove an unnecessary indentation in allocate_cache_info(). [ bp: Massage. ] • https://git.kernel.org/stable/c/6539cffa94957241c096099a57d05fa4d8c7db8a https://git.kernel.org/stable/c/23b5908b11b77ff8d7b8f7b8f11cbab2e1f4bfc2 https://git.kernel.org/stable/c/95e197354e0de07e9a20819bdae6562e4dda0f20 https://git.kernel.org/stable/c/b3fce429a1e030b50c1c91351d69b8667eef627b •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-56616 – drm/dp_mst: Fix MST sideband message body length check
https://notcve.org/view.php?id=CVE-2024-56616
In the Linux kernel, the following vulnerability has been resolved: drm/dp_mst: Fix MST sideband message body length check Fix the MST sideband message body length check, which must be at least 1 byte accounting for the message body CRC (aka message data CRC) at the end of the message. This fixes a case where an MST branch device returns a header with a correct header CRC (indicating a correctly received body length), with the body length being incorrectly set to 0. This will later lead to a memory corruption in drm_dp_sideband_append_payload() and the following errors in dmesg: UBSAN: array-index-out-of-bounds in drivers/gpu/drm/display/drm_dp_mst_topology.c:786:25 index -1 is out of range for type 'u8 [48]' Call Trace: drm_dp_sideband_append_payload+0x33d/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper] memcpy: detected field-spanning write (size 18446744073709551615) of single field "&msg->msg[msg->curlen]" at drivers/gpu/drm/display/drm_dp_mst_topology.c:791 (size 256) Call Trace: drm_dp_sideband_append_payload+0x324/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper] • https://git.kernel.org/stable/c/780fa184d4dc38ad6c4fded345ab8f9be7a63e96 https://git.kernel.org/stable/c/c58947a8d4a500902597ee1dbadf0518d7ff8801 https://git.kernel.org/stable/c/1fc1f32c4a3421b9d803f18ec3ef49db2fb5d5ef https://git.kernel.org/stable/c/bd2fccac61b40eaf08d9546acc9fef958bfe4763 •