CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-27027 – dpll: fix dpll_xa_ref_*_del() for multiple registrations
https://notcve.org/view.php?id=CVE-2024-27027
In the Linux kernel, the following vulnerability has been resolved: dpll: fix dpll_xa_ref_*_del() for multiple registrations Currently, if there are multiple registrations of the same pin on the same dpll device, following warnings are observed: WARNING: CPU: 5 PID: 2212 at drivers/dpll/dpll_core.c:143 dpll_xa_ref_pin_del.isra.0+0x21e/0x230 WARNING: CPU: 5 PID: 2212 at drivers/dpll/dpll_core.c:223 __dpll_pin_unregister+0x2b3/0x2c0 The problem is, that in both dpll_xa_ref_dpll_del() and dpll_xa_ref_pin_del() registration is only removed from list in case the reference count drops to zero. That is wrong, the registration has to be removed always. To fix this, remove the registration from the list and free it unconditionally, instead of doing it only when the ref reference counter reaches zero. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dpll: corrige dpll_xa_ref_*_del() para múltiples registros Actualmente, si hay múltiples registros del mismo pin en el mismo dispositivo dpll, se observan las siguientes advertencias: ADVERTENCIA: CPU: 5 PID: 2212 en drivers/dpll/dpll_core.c:143 dpll_xa_ref_pin_del.isra.0+0x21e/0x230 ADVERTENCIA: CPU: 5 PID: 2212 en drivers/dpll/dpll_core.c:223 __dpll_pin_unregister+0x2b3/0x2c0 El problema es que Tanto en dpll_xa_ref_dpll_del() como en dpll_xa_ref_pin_del() el registro solo se elimina de la lista en caso de que el recuento de referencias caiga a cero. Eso está mal, siempre hay que eliminar el registro. Para solucionar este problema, elimine el registro de la lista y libérelo incondicionalmente, en lugar de hacerlo sólo cuando el contador de referencia de referencia llegue a cero. • https://git.kernel.org/stable/c/9431063ad323ac864750aeba4d304389bc42ca4e https://git.kernel.org/stable/c/769324eb35143462542cdb15483cdaf4877bf661 https://git.kernel.org/stable/c/b27e32e9367dac024cd6f61f22655714f483fd67 https://git.kernel.org/stable/c/b446631f355ece73b13c311dd712c47381a23172 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-27026 – vmxnet3: Fix missing reserved tailroom
https://notcve.org/view.php?id=CVE-2024-27026
In the Linux kernel, the following vulnerability has been resolved: vmxnet3: Fix missing reserved tailroom Use rbi->len instead of rcd->len for non-dataring packet. Found issue: XDP_WARN: xdp_update_frame_from_buff(line:278): Driver BUG: missing reserved tailroom WARNING: CPU: 0 PID: 0 at net/core/xdp.c:586 xdp_warn+0xf/0x20 CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W O 6.5.1 #1 RIP: 0010:xdp_warn+0xf/0x20 ... ? xdp_warn+0xf/0x20 xdp_do_redirect+0x15f/0x1c0 vmxnet3_run_xdp+0x17a/0x400 [vmxnet3] vmxnet3_process_xdp+0xe4/0x760 [vmxnet3] ? vmxnet3_tq_tx_complete.isra.0+0x21e/0x2c0 [vmxnet3] vmxnet3_rq_rx_complete+0x7ad/0x1120 [vmxnet3] vmxnet3_poll_rx_only+0x2d/0xa0 [vmxnet3] __napi_poll+0x20/0x180 net_rx_action+0x177/0x390 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: vmxnet3: corrige la falta de espacio reservado. Use rbi->len en lugar de rcd->len para paquetes que no son de datos. Problema encontrado: XDP_WARN: xdp_update_frame_from_buff(line:278): ERROR del controlador: falta el cuarto de cola reservado ADVERTENCIA: CPU: 0 PID: 0 en net/core/xdp.c:586 xdp_warn+0xf/0x20 CPU: 0 PID: 0 Comm: swapper /0 Contaminado: GWO 6.5.1 #1 RIP: 0010:xdp_warn+0xf/0x20 ... ? • https://git.kernel.org/stable/c/54f00cce11786742bd11e5e68c3bf85e6dc048c9 https://git.kernel.org/stable/c/aba8659caf88017507419feea06069f529329ea6 https://git.kernel.org/stable/c/7c8505ecc2d15473d679b8e06335434b84fffe86 https://git.kernel.org/stable/c/91d017d19d5a9ad153e2dc23ed3c0e2e79ef5262 https://git.kernel.org/stable/c/e127ce7699c1e05279ee5ee61f00893e7bfa9671 •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-27025 – nbd: null check for nla_nest_start
https://notcve.org/view.php?id=CVE-2024-27025
In the Linux kernel, the following vulnerability has been resolved: nbd: null check for nla_nest_start nla_nest_start() may fail and return NULL. Insert a check and set errno based on other call sites within the same source code. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nbd: la comprobación nula de nla_nest_start nla_nest_start() puede fallar y devolver NULL. Inserte una marca y establezca errno según otros sitios de llamadas dentro del mismo código fuente. • https://git.kernel.org/stable/c/47d902b90a32a42a3d33aef3a02170fc6f70aa23 https://git.kernel.org/stable/c/44214d744be32a4769faebba764510888f1eb19e https://git.kernel.org/stable/c/4af837db0fd3679fabc7b7758397090b0c06dced https://git.kernel.org/stable/c/98e60b538e66c90b9a856828c71d4e975ebfa797 https://git.kernel.org/stable/c/96436365e5d80d0106ea785a4f80a58e7c9edff8 https://git.kernel.org/stable/c/b7f5aed55829f376e4f7e5ea5b80ccdcb023e983 https://git.kernel.org/stable/c/e803040b368d046434fbc8a91945c690332c4fcf https://git.kernel.org/stable/c/ba6a9970ce9e284cbc04099361c58731e •
CVSS: 7.8EPSS: 0%CPEs: 6EXPL: 0CVE-2024-27022 – fork: defer linking file vma until vma is fully initialized
https://notcve.org/view.php?id=CVE-2024-27022
In the Linux kernel, the following vulnerability has been resolved: fork: defer linking file vma until vma is fully initialized Thorvald reported a WARNING [1]. And the root cause is below race: CPU 1 CPU 2 fork hugetlbfs_fallocate dup_mmap hugetlbfs_punch_hole i_mmap_lock_write(mapping); vma_interval_tree_insert_after -- Child vma is visible through i_mmap tree. i_mmap_unlock_write(mapping); hugetlb_dup_vma_private -- Clear vma_lock outside i_mmap_rwsem! i_mmap_lock_write(mapping); hugetlb_vmdelete_list vma_interval_tree_foreach hugetlb_vma_trylock_write -- Vma_lock is cleared. tmp->vm_ops->open -- Alloc new vma_lock outside i_mmap_rwsem! hugetlb_vma_unlock_write -- Vma_lock is assigned!!! i_mmap_unlock_write(mapping); hugetlb_dup_vma_private() and hugetlb_vm_op_open() are called outside i_mmap_rwsem lock while vma lock can be used in the same time. • https://git.kernel.org/stable/c/8d9bfb2608145cf3e408428c224099e1585471af https://git.kernel.org/stable/c/0c42f7e039aba3de6d7dbf92da708e2b2ecba557 https://git.kernel.org/stable/c/04b0c41912349aff11a1bbaef6a722bd7fbb90ac https://git.kernel.org/stable/c/cec11fa2eb512ebe3a459c185f4aca1d44059bbf https://git.kernel.org/stable/c/dd782da470761077f4d1120e191f1a35787cda6e https://git.kernel.org/stable/c/abdb88dd272bbeb93efe01d8e0b7b17e24af3a34 https://git.kernel.org/stable/c/35e351780fa9d8240dd6f7e4f245f9ea37e96c19 https://access.redhat.com/security/cve/CVE-2024-27022 • CWE-908: Use of Uninitialized Resource •
CVSS: 7.8EPSS: 0%CPEs: 2EXPL: 0CVE-2024-27021 – r8169: fix LED-related deadlock on module removal
https://notcve.org/view.php?id=CVE-2024-27021
In the Linux kernel, the following vulnerability has been resolved: r8169: fix LED-related deadlock on module removal Binding devm_led_classdev_register() to the netdev is problematic because on module removal we get a RTNL-related deadlock. Fix this by avoiding the device-managed LED functions. Note: We can safely call led_classdev_unregister() for a LED even if registering it failed, because led_classdev_unregister() detects this and is a no-op in this case. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: r8169: corrige el punto muerto relacionado con el LED al eliminar el módulo. Vincular devm_led_classdev_register() al netdev es problemático porque al eliminar el módulo obtenemos un punto muerto relacionado con RTNL. Solucione este problema evitando las funciones LED administradas por el dispositivo. • https://git.kernel.org/stable/c/18764b883e157e28126b54e7d4ba9dd487d5bf54 https://git.kernel.org/stable/c/53d986f39acd8ea11c9e460732bfa5add66360d9 https://git.kernel.org/stable/c/19fa4f2a85d777a8052e869c1b892a2f7556569d • CWE-667: Improper Locking •