CVSS: -EPSS: %CPEs: 3EXPL: 0CVE-2024-50023 – net: phy: Remove LED entry from LEDs list on unregister
https://notcve.org/view.php?id=CVE-2024-50023
In the Linux kernel, the following vulnerability has been resolved: net: phy: Remove LED entry from LEDs list on unregister Commit c938ab4da0eb ("net: phy: Manual remove LEDs to ensure correct ordering") correctly fixed a problem with using devm_ but missed removing the LED entry from the LEDs list. This cause kernel panic on specific scenario where the port for the PHY is torn down and up and the kmod for the PHY is removed. On setting the port down the first time, the assosiacted LEDs are correctly unregistered. The associated kmod for the PHY is now removed. The kmod is now added again and the port is now put up, the associated LED are registered again. On putting the port down again for the second time after these step, the LED list now have 4 elements. With the first 2 already unregistered previously and the 2 new one registered again. This cause a kernel panic as the first 2 element should have been removed. Fix this by correctly removing the element when LED is unregistered. • https://git.kernel.org/stable/c/c938ab4da0eb1620ae3243b0b24c572ddfc318fc https://git.kernel.org/stable/c/143ffa7878e2d9d9c3836ee8304ce4930f7852a3 https://git.kernel.org/stable/c/fba363f4d244269a0ba7abb8df953a244c6749af https://git.kernel.org/stable/c/f50b5d74c68e551667e265123659b187a30fe3a5 •
CVSS: -EPSS: %CPEs: 4EXPL: 0CVE-2024-50022 – device-dax: correct pgoff align in dax_set_mapping()
https://notcve.org/view.php?id=CVE-2024-50022
In the Linux kernel, the following vulnerability has been resolved: device-dax: correct pgoff align in dax_set_mapping() pgoff should be aligned using ALIGN_DOWN() instead of ALIGN(). Otherwise, vmf->address not aligned to fault_size will be aligned to the next alignment, that can result in memory failure getting the wrong address. It's a subtle situation that only can be observed in page_mapped_in_vma() after the page is page fault handled by dev_dax_huge_fault. Generally, there is little chance to perform page_mapped_in_vma in dev-dax's page unless in specific error injection to the dax device to trigger an MCE - memory-failure. In that case, page_mapped_in_vma() will be triggered to determine which task is accessing the failure address and kill that task in the end. We used self-developed dax device (which is 2M aligned mapping) , to perform error injection to random address. It turned out that error injected to non-2M-aligned address was causing endless MCE until panic. Because page_mapped_in_vma() kept resulting wrong address and the task accessing the failure address was never killed properly: [ 3783.719419] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.049006] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.049190] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.448042] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.448186] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.792026] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.792179] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.162502] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.162633] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.461116] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.461247] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.764730] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.764859] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.042128] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.042259] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.464293] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.464423] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.818090] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.818217] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3787.085297] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3787.085424] Memory failure: 0x200c9742: recovery action for dax page: Recovered It took us several weeks to pinpoint this problem, but we eventually used bpftrace to trace the page fault and mce address and successfully identified the issue. Joao added: ; Likely we never reproduce in production because we always pin : device-dax regions in the region align they provide (Qemu does : similarly with prealloc in hugetlb/file backed memory). • https://git.kernel.org/stable/c/b9b5777f09be84d0de472ded2253d2f5101427f2 https://git.kernel.org/stable/c/9c4198dfdca818c5ce19c764d90eabd156bbc6da https://git.kernel.org/stable/c/b822007e8db341d6f175c645ed79866db501ad86 https://git.kernel.org/stable/c/e877427d218159ac29c9326100920d24330c9ee6 https://git.kernel.org/stable/c/7fcbd9785d4c17ea533c42f20a9083a83f301fa6 •
CVSS: -EPSS: %CPEs: 2EXPL: 0CVE-2024-50021 – ice: Fix improper handling of refcount in ice_dpll_init_rclk_pins()
https://notcve.org/view.php?id=CVE-2024-50021
In the Linux kernel, the following vulnerability has been resolved: ice: Fix improper handling of refcount in ice_dpll_init_rclk_pins() This patch addresses a reference count handling issue in the ice_dpll_init_rclk_pins() function. The function calls ice_dpll_get_pins(), which increments the reference count of the relevant resources. However, if the condition WARN_ON((!vsi || !vsi->netdev)) is met, the function currently returns an error without properly releasing the resources acquired by ice_dpll_get_pins(), leading to a reference count leak. To resolve this, the check has been moved to the top of the function. • https://git.kernel.org/stable/c/d7999f5ea64bb10d2857b8cbfe973be373bac7c9 https://git.kernel.org/stable/c/aefecead9d08f4a35ab6f51ba2e408d2cef4e31d https://git.kernel.org/stable/c/ccca30a18e36a742e606d5bf0630e75be7711d0a •
CVSS: -EPSS: %CPEs: 3EXPL: 0CVE-2024-50020 – ice: Fix improper handling of refcount in ice_sriov_set_msix_vec_count()
https://notcve.org/view.php?id=CVE-2024-50020
In the Linux kernel, the following vulnerability has been resolved: ice: Fix improper handling of refcount in ice_sriov_set_msix_vec_count() This patch addresses an issue with improper reference count handling in the ice_sriov_set_msix_vec_count() function. First, the function calls ice_get_vf_by_id(), which increments the reference count of the vf pointer. If the subsequent call to ice_get_vf_vsi() fails, the function currently returns an error without decrementing the reference count of the vf pointer, leading to a reference count leak. The correct behavior, as implemented in this patch, is to decrement the reference count using ice_put_vf(vf) before returning an error when vsi is NULL. Second, the function calls ice_sriov_get_irqs(), which sets vf->first_vector_idx. If this call returns a negative value, indicating an error, the function returns an error without decrementing the reference count of the vf pointer, resulting in another reference count leak. The patch addresses this by adding a call to ice_put_vf(vf) before returning an error when vf->first_vector_idx < 0. This bug was identified by an experimental static analysis tool developed by our team. • https://git.kernel.org/stable/c/4d38cb44bd321c81da3457cfbc38501ed8cb6714 https://git.kernel.org/stable/c/3345e7cf0cf82027bff3b7878bd79214688e61da https://git.kernel.org/stable/c/416dbb815ca69684de148328990ba0ec53e6dbc1 https://git.kernel.org/stable/c/d517cf89874c6039e6294b18d66f40988e62502a •
CVSS: -EPSS: %CPEs: 5EXPL: 0CVE-2024-50019 – kthread: unpark only parked kthread
https://notcve.org/view.php?id=CVE-2024-50019
In the Linux kernel, the following vulnerability has been resolved: kthread: unpark only parked kthread Calling into kthread unparking unconditionally is mostly harmless when the kthread is already unparked. The wake up is then simply ignored because the target is not in TASK_PARKED state. However if the kthread is per CPU, the wake up is preceded by a call to kthread_bind() which expects the task to be inactive and in TASK_PARKED state, which obviously isn't the case if it is unparked. As a result, calling kthread_stop() on an unparked per-cpu kthread triggers such a warning: WARNING: CPU: 0 PID: 11 at kernel/kthread.c:525 __kthread_bind_mask kernel/kthread.c:525 <TASK> kthread_stop+0x17a/0x630 kernel/kthread.c:707 destroy_workqueue+0x136/0xc40 kernel/workqueue.c:5810 wg_destruct+0x1e2/0x2e0 drivers/net/wireguard/device.c:257 netdev_run_todo+0xe1a/0x1000 net/core/dev.c:10693 default_device_exit_batch+0xa14/0xa90 net/core/dev.c:11769 ops_exit_list net/core/net_namespace.c:178 [inline] cleanup_net+0x89d/0xcc0 net/core/net_namespace.c:640 process_one_work kernel/workqueue.c:3231 [inline] process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 worker_thread+0x86d/0xd70 kernel/workqueue.c:3393 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Fix this with skipping unecessary unparking while stopping a kthread. • https://git.kernel.org/stable/c/5c25b5ff89f004c30b04759dc34ace8585a4085f https://git.kernel.org/stable/c/40a6e660d2a3a7a5cb99f0b8ff4fb41bad039f68 https://git.kernel.org/stable/c/8608196a155cb6cfae04d96b10a2652d0327e33f https://git.kernel.org/stable/c/19a5029981c87c2ad0845e713837faa88f5d8e2b https://git.kernel.org/stable/c/cda5423c1a1c906062ef235c940f249b97d9d135 https://git.kernel.org/stable/c/214e01ad4ed7158cab66498810094fac5d09b218 •